Risk & Compliance Group

Applicable directions: Finance / Compliance / Legal / Audit / Security

Nature of the specification: the documents in this group are a compilation of industry research and engineering practice, in which the cited laws, regulations and national/international standards are subject to the original text; the AGENTS.md and SKILL.md given here are engineering conventions, not official standards issued by standards organizations.

1. Introduction

1.1 Positioning of the Group

The Risk & Compliance group covers five directions: Finance, Compliance, Legal, Audit, and Security. Under the AI Harness six-layer capability model (L1 Context Engineering, L2 Tools & Execution, L3 Orchestration & Control, L4 Memory & State, L5 Evaluation & Observation, L6 Governance & Security), this group carries the highest weight on the L6 Governance & Security layer of the six groups.

What these five directions have in common is not "using AI to boost efficiency", but this: the output of AI gets examined as evidence by third parties (regulators, judicial authorities, clients, counterparties, and attackers).

In the software engineering group, if the model makes a mistake in a line of code, the worst outcome is a failed build or a rejection in code review; in the Risk & Compliance group, if the model fabricates a legal provision, misses a suspicious transaction, or misjudges an alert, the consequences can be administrative penalties, lost lawsuits, financial losses, or security incidents. This difference determines that this group's technical focus is not "how to make the model smarter", but on how to make the model's behavior provable, reviewable, and accountable.

图 1-1｜AI Harness 六层体系与风险合规组的定位

数据来源：基于本文分析绘制的示意图。

1.2 Why L6 Is the "Main Product" Here, Not the "Support"

In other groups, L6 is a constraint — it limits what an Agent can do; in this group, L6's outputs themselves are the final deliverables handed to regulators, boards of directors, and courts:

This table makes one thing clear: if this group's Harness build only covers L1–L5, the deliverables are incomplete — it omits precisely the part that gets externally scrutinized.

Three main threads run throughout the group:

• Auditable: external review is not about "whether the model is good", but "what you relied on when making this judgment, whether that basis was real, and whether the process is reproducible".
• Traceable: a regulatory filing, a contract review opinion, or an audit working paper, when spot-checked months or even years later, must be reproducible back to the corpus version and the rules version in force at the time.
• Human in the loop: a large number of actions in this group are irreversible, and irreversible actions must never be executed autonomously by the model.

1.3 Boundaries with the Other Five Groups

2. Positioning Comparison of the Five Directions

2.1 Positioning Comparison Table

2.2 Irreversible Actions vs. Permissions

Security is the only direction in this group that allows the Agent to execute destructive actions within a limited scope, so its requirements on the L2 Tools & Execution layer (sandbox, least privilege, dry-run rehearsal) are the highest.

2.3 Coupling Relationships between Directions

                 ┌──────────── Security（基座：数据不出域 / 沙箱 / 日志 / AI BOM）────────────┐
                 │                                                                          │
        ┌────────┴────────┐   ┌──────────────┐   ┌──────────────┐   ┌──────────────┐        │
        │    Finance      │   │  Compliance  │   │    Legal     │   │    Audit     │        │
        │（风控/反洗钱）  │◄─►│（外规内化/报送）│◄─►│（合同/诉讼） │   │（元审计）    │        │
        └─────────────────┘   └──────────────┘   └──────────────┘   └──────┬───────┘        │
                                                                             │               │
                                                             审计覆盖其余四个方向的 AI 系统 ◄┘

• Finance ↔ Compliance: the same AI application in a financial institution is simultaneously bound by "model risk" (the three pillars of SR 11-7) and "compliance obligations" (ISO 37301); AML belongs to both directions — Finance deals with detection technology, Compliance deals with filing obligations and governance architecture.
• Compliance ↔ Legal: internalizing external regulations (Compliance) and implementing contract clauses (Legal) are the two ends of the same chain.
• Audit ↔ All: audit is a meta-audit of the AI systems across the four directions Finance / Compliance / Legal / Security.
• Security ↔ All: Security provides the foundational capabilities shared by the other four directions (data never leaves the domain, sandboxing, logging, and the AI bill of materials).

3. Mapping the Five Directions to the Harness Six Layers

3.1 Direction × Six-Layer Mapping Table

3.2 Identifying the Bottleneck Layer for Each Direction

4. Common Challenges and Countermeasures

4.1 Challenge One: Auditable — Conclusions Must Be Reproducible Back to Their Basis

Problem: LLM output is probabilistic, while the regulatory requirement "what you relied on when making this judgment" is deterministic.

Countermeasure: bind every output to a five-tuple — input snapshot + tool-call log + output + manual confirmation record + hash. This is structurally isomorphic to Article 19 of the Interim Measures for the Administration of Generative AI Services, which requires providers to explain the "source, scale, type, annotation rules, and algorithm mechanism/handling of training data".

Acceptance criterion: any historical conclusion must be reproducible within 10 minutes back to "what was seen at the time, which rule version and which model version were used, and who approved it".

4.2 Challenge Two: Traceable — Version Drift Causes the "Basis to Become Invalid"

Problem: regulations get revised, precedents get overturned, internal policies get updated. Semantic-similarity retrieval cannot distinguish "currently in force" from "repealed".

Countermeasure: L1 retrieval must perform structured filtering (effectiveness tier + effective / expiry dates + scope of application), and forcibly carry source and effective-date markers in the output. ISO 37301:2021 / GB/T 35770—2022 require organizations to identify and maintain compliance obligations; the "time effectiveness" of compliance obligations is an implicit requirement within this.

Acceptance criterion: no expired versions may appear in the retrieval result set; if a historical version must genuinely be cited (e.g., the legal status at the time of an action), it must be explicitly marked "historical version, for determining the state at that time only".

4.3 Challenge Three: The Human-in-the-Loop Becomes a Mere Formality

Problem: implementing "manual confirmation" as a pop-up you just click away is the same as not confirming at all.

Countermeasure:

• Manual confirmation must be a recorded action that carries identity, timestamp, and a snapshot of the confirmed content, not a boolean switch.
• Under Article 4.3.1 of GB/T 45654—2025, according to which "in the same annotation task, the annotation executor and the annotation reviewer should not be the same person", implement segregation of duties (SoD) directly as: the generation Agent and the review Agent must not share the same identity or the same credentials.
• Externalize trigger conditions into a checklist (amount thresholds, irreversible actions, cross-jurisdiction, regulatory filing) rather than relying on the model's own judgment.

4.4 Challenge Four: The Asymmetric Cost of Hallucination

Problem: in general scenarios a hallucinated answer is a "UX issue"; in this group, fabricating a legal provision, a precedent, or a regulatory stance is a professional incident.

Countermeasure:

• Never treat model output as verified fact (corresponding to LLM09 — Misinformation in OWASP LLM Top 10 2025).
• Citations must return the original-text snippet and the source link; any citation that cannot return a source is void.
• For law, precedent, and regulatory-stance content, adopt "retrieve first, generate after"; when no search result is hit, output "no basis found" instead of speculating.
• The direction publicly pointed out by GF Securities is worth borrowing: establish scenario-based hallucination-tolerance grading standards and fault-tolerance mechanisms, and use a constrained instruction framework to control hallucination (per the 21st Century Business Herald, April 2026 report).

4.5 Challenge Five: Data Classification and Exit-Domain Control

Problem: the compliance, legal, and audit scenarios often process clients' confidential information and personal information.

Countermeasure (direct quote from the regulator): the CICPA's 2026-03-05 risk-prevention notice explicitly requires that, without client authorization or legal/regulatory permission, confidential information must not be entered into or uploaded to public AI platforms; before using AI tools to process client data, one must ensure that the technical environment, data flow, and access permissions are in a secure and strictly controlled state.

Technical implementation: data-classification labels (public / internal / secret / confidential / personal information) + exit-domain interception + desensitization (PII scrubbing) + minimal-necessary collection. Article 4.2.3 of GB/T 45654—2025 requires obtaining separate consent before using training data containing sensitive personal information; Article 4.1.1 gives a quantitative threshold: conduct a randomized-sample security assessment before collection, and data containing more than 5% illegal/harmful information should not be collected.

4.6 Challenge Six: AI Itself Becoming an Object of Attack and Audit

Problem: IBM's Cost of a Data Breach Report 2025 (released 2025-07-30) shows: 13% of organizations reported breaches of their AI models or applications, with another 8% uncertain; among the breached organizations, 97% reported having no AI access controls deployed; 63% of breached organizations either had no AI governance policy or were still drafting one; one in five organizations reported a breach due to shadow AI.

Countermeasure: AI-asset registration (AI BOM), AI telemetry logging, guardrails, and least privilege — these three are precisely the categories of key mitigation measures given by MITRE ATLAS. This group therefore requires: the access controls, logging, and governance policies of AI systems themselves must be protected to the same degree as the business data they process.

5. The AIxCC Paradigm: How Model Uncertainty Is Reconciled by Engineering Determinability

5.1 The Origin of the Paradigm

The DARPA AI Cyber Challenge (AIxCC) finals were held in August 2025 at DEF CON 33. The Cyber Reasoning Systems (CRS) of the seven finalist teams performed identification and patching of synthetic vulnerabilities across 54 million lines of code. The official results published by DARPA are:

The champion was Team Atlanta (ATLANTIS, $4 million prize), runner-up Trail of Bits (Buttercup, $3 million), and third place Theori ($1.5 million).

These numbers are impressive on their own, but for AI Harness, what is truly valuable is the common architecture that the seven teams converged on.

5.2 Dissecting the Three-Layer Architecture

┌─────────────────────────────────────────────────────────────┐
│  第 3 层：编排层（LLM）                                      │
│  语义推理：发现可疑模式 / 生成假设 / 决定调哪个工具 /         │
│  读取结果 / 精炼假设 / 迭代 / 编写 PoV 与补丁                 │
└───────────────────────────┬─────────────────────────────────┘
                            │ 编排调用
┌───────────────────────────▼─────────────────────────────────┐
│  第 2 层：经典确定性分析工具                                  │
│  定向 fuzzing（AFL++ / libFuzzer）                           │
│  符号执行（KLEE / angr / Mayhem）                            │
│  静态分析（CodeQL / Semgrep / Joern）                        │
└───────────────────────────┬─────────────────────────────────┘
                            │ 输出可复现证据
┌───────────────────────────▼─────────────────────────────────┐
│  第 1 层：判定层                                              │
│  漏洞以可复现的崩溃（Proof of Vulnerability, PoV）确认，      │
│  而非模型的"直觉"                                            │
└─────────────────────────────────────────────────────────────┘

In one sentence: the LLM does not do vulnerability hunting — it orchestrates the tools that do the hunting and interprets the results; vulnerabilities are confirmed by reproducible PoVs, not by the model's "intuition".

5.3 Rolling Out to the Whole Group: The General Principle of Determining Where Judgment Resides

The AIxCC paradigm answers this group's most fundamental question — how do model uncertainty and engineering predictability coexist. The answer is layered, not solved by "a stronger model":

This principle has a consistent mapping across this group's five directions:

• Security: vulnerabilities are confirmed by PoV crashes, not by the model saying "there might be a bug here". Every finding from Google Big Sleep was validated by Project Zero analysts before disclosure — the SQLite vulnerability CVE-2025-6965 (CVSS 7.2), found via threat intelligence in 2025, was handled through exactly this process.
• Audit: the CICPA requires that for anomalies identified by AI, "further audit procedures be taken to confirm whether there is a risk of material misstatement", and the data obtainable from official platforms may be used for verification — AI provides clues; audit procedures provide the evidence.
• Legal: the conclusion of clause extraction must be traceable back to the specific location and page number in the original contract; legal-provision citations must trace back to the original regulation text.
• Compliance: every field of a filing message must be traceable back to the source-system data and the mapping-rule version.
• Finance: a risk-control signal gives "a candidate worth human attention"; the credit decision is made by humans (signal vs. decision separation).

Cross-cutting conclusion: the jump in AIxCC from an "identification rate of 37%→86%" happened not because the model got stronger, but because the orchestration layer learned when to call which deterministic tool, and when to abandon a hypothesis. This suggests that this group's Harness investment focus should be the "tool-orchestration and evidence-judgment chain", rather than "a bigger model".

One piece of supporting evidence: CyberSentinel-LLM (published in Computers, Materials & Continua vol.89 no.1, 2025), in a study on HDFS log streams, showed that 8 SOC analysts rated the reduction of "repetitive triage work" at 4.6/5.0, but trust in autonomous response suggestions was only 3.9/5.0 — the paper therefore recommends first releasing in "detection-only" mode and enabling automated response later. Capability recognition exceeding trust is the most direct empirical support for the "detect first, auto-respond later" progressive-authorization path.

6. Overview of the Regulatory and Standards Foundation

6.1 China Side

6.2 International Side

7. Group-Level Specifications and Document Navigation

7.1 Document List

7.2 Reading Paths

• Architecture decision-makers: README → AGENTS.md → 05-security.md (AIxCC paradigm) → 04-audit.md (meta-audit perspective)
• Compliance / legal leads: README Chapter 4 → 02-compliance.md → 03-legal.md
• Model-risk leads at financial institutions: 01-finance.md → 02-compliance.md (AML filing obligations) → 04-audit.md
• Security-engineering leads: 05-security.md → README Chapter 5 → AGENTS.md (authorization red lines)

Specification-hierarchy principle: the group-level AGENTS.md defines the "non-waivable baselines", and the direction-level AGENTS.md (in Section 4.1 of each direction document) defines the "SOP for that scenario". The direction level may be stricter, never looser.

8. Summary

The founding principle of the Risk & Compliance group is one sentence: here, L6 is not a constraint but a product.

Three judgments are worth remembering:

1. Accountability cannot be transferred. CICPA (2026-03-05) "does not reduce the responsibility CPAs bear for audit opinions", IESBA (2026) "regardless of the degree of automation or technical complexity, professional accountants remain responsible for their judgments and decisions", the Supreme People's Court (2025-04) "the subjects that make judicial decisions and bear judicial responsibility are the adjudicators", and HKMA (2026-06-22) "technology does not replace governance" — four institutions across three jurisdictions reached the same conclusion. This means this group's Harness design goal is not to "replace people", but to "enable people to be accountable".

1. Determination authority must not be handed to probability. The AIxCC PoV reproducible-confirmation paradigm gives the engineering answer: the model is responsible for hypotheses and orchestration, while the deterministic tools and the people who sign are responsible for determination. Beyond Security, this paradigm also applies to audit forensics, contract comparison, flow verification, and compliance mapping.

1. Detect first, auto-respond later. The research conclusion that capability recognition (4.6/5.0) exceeds trust (3.9/5.0), combined with Google Big Sleep's practice that "all findings must be validated by analysts before disclosure", together point to the progressive-authorization path.

If the software engineering group's Harness pursues "producing verifiable changes faster", then the Risk & Compliance group's Harness pursues "making accountable judgments more slowly, but in a way that can be evidenced". Slowness is this group's design goal, not a defect.

Information-Gap Statement

The following content could not be substantiated with A/B-grade first-hand evidence during research; the text has been handled per the "no fabrication" principle, and the items must be separately verified when used:

1. The original document number, release date, and clause numbers of the Financial Sector Science and Technology Ethics Guidelines — only quotations from PBOC officials' speeches and media republications were obtained; the 7 aspects (upholding integrity and innovation, data security, inclusive and universal benefit, openness and transparency, fair competition, risk prevention and control, green and low-carbon) are reliable, but the clause numbers were not confirmed.
2. The industry-standard numbers (JR/T numbers) and provisions of the Assessment Specification for AI Algorithm Financial Applications (2021) and the Information Disclosure Guidelines for AI Algorithm Financial Applications (2023).
3. The full name, release date, and clauses of the Supreme People's Court's Opinion on Standardizing and Strengthening the Judicial Application of AI — only the paraphrase that "by 2025 a fairly complete judicial-AI technology application system should basically be built" was obtained.
4. The details of the Annex A controls and the AI-related extensions of ISO/IEC 27001:2022 — only the standard version and release date were confirmed.
5. AI deployment cases of Chinese law firms and in-house corporate legal teams — everything retrieved was C-grade sources, which this group's documents have discarded and not included in the body text.
6. Quantified deployment cases of incident response (IR) and continuous audit on the China side.
7. Verifiable deployment cases in the AppSec direction of "AI code review / SAST false-positive reduction".
8. Securities-firm IT spending has two sets of statistical calibers (34 firms / RMB 27.59 billion / 6.2% of revenue; 28 firms / about RMB 25 billion / 6% share). This document adopts the former and notes the source; the two must not be mixed.
9. The EU AI Act timeline has version conflicts due to the AI Omnibus (provisional May 2026 agreement); this document uses the timeline published by the EU's official service desk as the baseline, and treats the Omnibus adjustments as "proposed".
10. The Shenzhen Intermediate Court's AI-assisted adjudication case-closure efficiency has two calibers — "a 25.6% reduction" and "a 38-day reduction" — and this document presents them side by side.
11. The two items of GB/T 45654—2025 — "the pass rate for generated compliant content is no less than 90%" and "the appendix lists 31 categories of risks" — are second-level interpretations whose original standard text was not verified, and are therefore not adopted in this document.
12. The complete list of the 12 categories of risks in NIST AI 600-1 (other sources claim 13 categories) and the classification details of the 400+ actions were not obtained from the original text.

9. References

1. Interim Measures for the Administration of Generative AI Services (Order No. 15 of seven departments including the Cyberspace Administration of China), 2023. https://www.cac.gov.cn/2023-07/13/c_1690898327029107.htm
2. Decision amending the Cybersecurity Law of the People's Republic of China (Presidential Order No. 61), newly adding Article 20, National People's Congress, 2025. http://www.npc.gov.cn/c2/c30834/202601/t20260105_450980.html
3. GB/T 45654—2025, Cybersecurity Technology — Basic Requirements for the Safety of Generative AI Services, National Cybersecurity Standardization Technical Committee (SAC/TC260), 2025. https://www.tc260.org.cn/tc260/hygd1/202403/b429d868525e48c3b7d12a0ec8f82e5e.shtml
4. Digital Finance High-Quality Development Implementation Plan for the Banking and Insurance Industry, General Office of the National Financial Regulatory Administration, 2025-12. https://www.nfra.gov.cn/cn/view/pages/ItemDetail.html?docId=1239741
5. CICPA Notice on Preventing the Risks of Using AI Technology in Accounting Firms' 2025 Annual Report Audits, Chinese Institute of Certified Public Accountants, 2026-03-05. https://cicpa.org.cn/xxfb/news/202603/t20260305_65842.html
6. NIST AI Risk Management Framework (AI RMF 1.0), NIST, 2023. https://www.nist.gov/itl/ai-risk-management-framework
7. NIST AI 600-1, Generative Artificial Intelligence Profile, NIST, 2024. https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence
8. ISO/IEC 42001:2023, Information technology — Artificial intelligence — Management system, ISO/IEC JTC 1/SC 42, 2023. https://www.iso.org/standard/42001
9. ISO 37301:2021 / GB/T 35770—2022, Compliance Management Systems — Requirements with Guidance for Use, China National Institute of Standardization, 2022. https://www.cnis.ac.cn/bydt/zhxw/202210/t20221020_54060.html
10. EU AI Act, Regulation (EU) 2024/1689 — Implementation Timeline, European Commission AI Act Service Desk. https://ai-act-service-desk.ec.europa.eu/en/ai-act/timeline/timeline-implementation-eu-ai-act
11. SR 11-7, Supervisory Guidance on Model Risk Management, Federal Reserve & OCC, 2011 (compiled by BPI). https://bpi.com/wp-content/uploads/2024/04/Navigating-Artificial-Intelligence-in-Banking.pdf
12. IAASB proposed revisions to ISA 330 / 500 / 520, IAASB, 2026. https://www.iaasb.org/news-events/2026-02/iaasb-publishes-global-roundtable-feedback-technology-and-quality-management
13. IIA, Global Internal Audit Standards (2024), The Institute of Internal Auditors. https://www.theiia.org/en/standards/documents/
14. OWASP Top 10 for LLM Applications (2025 edition), OWASP GenAI Security Project. https://genai.owasp.org/llm-top-10/
15. MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems), MITRE. https://atlas.mitre.org
16. DARPA AI Cyber Challenge final results, DARPA, 2025. https://www.darpa.mil/news/2025/aixcc-results
17. Google, Cybersecurity updates: Summer 2025 (Big Sleep, Timesketch + Sec-Gemini, FACADE), Google, 2025. https://blog.google/technology/safety-security/cybersecurity-updates-summer-2025/
18. IBM, Cost of a Data Breach Report 2025, IBM / Ponemon Institute, 2025-07-30. https://newsroom.ibm.com/2025-07-30-ibm-report-13-of-organizations-reported-breaches-of-ai-models-or-applications,-97-of-which-reported-lacking-proper-ai-access-controls
19. HKMA, Supporting Adoption of Artificial Intelligence in Fighting Financial Crime, Hong Kong Monetary Authority, 2026-06-22. https://brdr.hkma.gov.hk/eng/doc-ldg/current/20260622-1-EN
20. CyberSentinel-LLM, Computers, Materials & Continua, vol.89, no.1, 2025, Tech Science Press. https://www.techscience.com/cmc/v89n1/68397/html