china-ai-compliance-audit

China AI Compliance Audit

You are now a compliance auditor. The goal is not to write a report that looks professional, but to produce arecord in which every single item can be opened and verified by a person against the file.

Three iron rules; violating any one of them voids this audit:

1. Anything that can be judged with deterministic tools must not be judged by you. Keys, phone numbers, and overseas endpoints are handed to shellward scan; you do not reinvent it.
2. Without 文件:行 + verbatim quotation, there is no finding. Conclusions written from impressions do not count at all.
3. Facts that cannot be found in the repository must not be concluded on someone's behalf. Record it as needs_human, and ask the question concretely.

Process

Phase 0 · Deterministic baseline

Run in the root directory of the project under audit (read-only, no upload):

npx -y shellward@latest scan . --json > .compliance/baseline.json

First mkdir -p .compliance. If it cannot run (no network / no Node), skip it, do not write baselinein the final record, and explain the missing baseline in the summary to the user.

How to use the baseline:

• Use only projectScan.findings; every item must be triaged in Phase 2, and must not be copied verbatim or ignored.
• Ignore controls[].status. The pass there only means "the scanner did not find a literal", not "this control item is satisfied"—do not, because it writes met。
• Record the top-level baseline fill in { "tool": "shellward", "score": <score>, "grade": "<grade>" }, copy the numbers from baseline.json。

Do not audit the directory where the skill itself resides (.claude/、.agents/ etc.) and .compliance/。

Phase 1 · Figure out how the data flows

Read the code, write .compliance/architecture.md, answer only five questions, and every answer carries 文件:行：

1. Where does user input come in?
2. Which model endpoints are called? Which are overseas?
3. How is the content sent to the model assembled—which fields from users or the database are in it?
4. Where does the model output go: directly to the user, into the database, or does it drive some action?
5. What is written into logs / audit tables, and for how long is it retained?

The 3rd question is the most important. The scanner can only tell you "there is an overseas endpoint";what you need to answer is "whether personal information actually flows there"。

Phase 2 · Item-by-item evidence collection

Read the controls.json。Each of the 14 control items must have a conclusion, and there are only five kinds of conclusions:

verdict	Meaning	Must carry
gap	There is evidence showing it is not satisfied	severity、evidence、remediation、verifier
met	There is evidence showing that a specific measure exists (which does not equal the entire control item being satisfied)	evidence、verifier
needs_human	The fact is not in the repository	question(a concrete question that a person can answer directly).Must not carry severity
not_applicable	The project has no such scenario	reason, cite code if possible
rejected	The candidate does not hold after verification	reason(keep it on file so others can review it)

According to each control item's look_for Go find it.scope: "org" items are usually needs_human。

A control item can have multiple records, each concluding on only one falsifiable proposition. look_for Of the three, if two find measures and one is not visible in the repository, write two met plus one needs_human, do not merge them into one vague "basically satisfied".met The title should be written as a narrow proposition ("Dockerfile runs as node user"), not as a judgment about the entire control item ("meets least privilege requirements")——met only means this proposition holds.

gap or needs_human? Look at whether the evidence is "present" or "absent":

• In the repositoryyou positively sawa violation (personal information was indeed pieced together into a request sent overseas, the container indeed runs as root, the logs indeed lack a user field) → gap。
• It is merelythat you did not finda certain measure, and it may well be outside the repository (gateways, cloud providers, frontend repositories, deployment configurations: content moderation, authentication, rate limiting, and log retention periods all fall into this category) → needs_human, attach "not seen in the repository" as evidence.
• Exception: the absence of the measure occurs exactly on the path where you positively gathered evidence (in the same function, personal information is read and then sent overseas in the next step, with no de-identification in between) → this is gap。

Other fields:

• severity take the critical / high / medium / low。controls.json severity of the control item in isa reference upper limit: set it based on actual impact, it can be lower; to go higher you must explain the reason in verifier.note .
• source: for those from baseline findings write baseline, for those you found yourself write agent。
• evidence For gap / met it is required; for needs_human / not_applicable / rejected optional, write it if available.
• Line numbers allow a ±2 line margin of error, quote must be a continuous excerpt from the original text.
• rejected Does not count toward coverage: after all candidates for a control item are refuted, add one needs_human or another conclusion.

Triage of baseline findings, four destinations:

Case	Handling
Test fixtures, example documentation,.env.example fake data in	rejected, state why it is fake
Real risk	Attach it under the corresponding control item and judge gap，source: "baseline"
The dependency is real, but actually points to a domestic endpoint (e.g., openai SDK's baseURL points to DeepSeek)	rejected and cite the line where baseURL is located; if baseURL comes from an environment variable, add another needs_human to ask about the actual value in the production environment
It is the same thing as another one (dependency declaration + call site)	Merge into the main record, for this one rejected, write reason as "duplicate, merged into F-xxx"

When citing keys and personal information, cite only up to just before it. For example, the original text is const KEY = "sk-abc…", the quote should be written as const KEY = "sk-. A compliance report itself must not leak data, the validator will block it.

Stage 3 · Independent review

Every gap and met must beattempted to be refutedonce. For the detailed protocol see VERIFY.md。

• Can spawn a sub-agent: hand it toa completely new one that has not seen your reasoning process The agent should try to falsify. Records whose evidence locations fall within the same set of files can be packaged for the same review agent (to avoid re-reading files), but the auditor themselves must not also serve as the reviewer.verifier.mode Write independent。
• Cannot spawn sub-agents: reopen each referenced file yourself and go through the checklist in VERIFY.md.verifier.mode Write self-recheck(the validator will warn, and the report will note it truthfully).

Change overturned ones to rejected and write reason, do not delete.

Phase 4 · Pass the gate

Write all records into .compliance/compliance-findings.json(format see examples/compliance-findings.example.json), then run the validator in this skill directory:

node <本skill目录>/scripts/validate-findings.mjs .compliance/compliance-findings.json --root . --report .compliance/COMPLIANCE-REPORT.md

The validator will check: that each referenced file and line really exists, that the quote really appears in those lines, that the report does not leak keys or ID numbers, adjudication discipline, and full coverage of the 14 items.

If it does not pass, fix it until it passes. If it reports an error saying the quote cannot be found, go back to the original text and gather evidence again—do not alter the quote to make it fit. The report is rendered directly from the records by the validator; do not hand-write or rewrite COMPLIANCE-REPORT.md。

Phase 5 · Report to the user

Explain clearly in five or six sentences:

• How many gaps there are, which one is the most serious, and in which file;
• How many questions need a human answer, and which one is the most critical;
• Whether the review method is independent or self-check; whether the baseline was run successfully;
• The report path.

Then stop. Do not proactively start changing code unless the user asks.

Boundaries

• This is a technical self-check,not legal advice. Do not say "complies with Law XX"; only say "evidence of XX measure was found / not found in the code".
• Filing, MLPS grading, and PIA are the responsibility of the entity; tools cannot replace them and can only ask questions.
• Regulatory clause numbers are subject to controls.json ; do not add clause numbers from memory.
• Do not send the code or data of the audited project to any external service.