Direct answer
Five steps: scope the channels, build a ledger, clear the 48 shall items first (especially the five automatic-handover scenarios in 5.2.2.6), leave evidence for each item, and set a re-check cycle. The checklist has 61 items (48 shall + 4 should + 9 may, including 5 deal-breakers) — work through the 48 shall items before the rest. Then test with real customer questions, including deliberately awkward ones, and record every requirement you cannot yet satisfy with the reason.
Step 1 — read the handover clauses, not the whole standard
Start at 5.2, the handover section, rather than at the beginning. This is where the operational requirements sit, and it is where a gap has the most direct effect on a customer.
Produce a plain list of requirements in your own words, each with its clause number beside it. If you cannot write a requirement in your own words, you do not yet understand it well enough to check it.
Step 2 — find where each requirement actually lives
For each item on the list, locate the configuration that implements it: a setting, a script, a rule, or a documented manual practice. Two outcomes are equally informative:
- You find it — record where it is and who owns it.
- You cannot find it — record that too. A requirement with no location is a finding, and usually the important one.
The most common result at this step is discovering that a handover setting exists on paper but is switched off, or is set to a value nobody chose.
Put the ledger on the 61-item checklist rather than on the clause numbers: 31 clauses become 61 items, so one clause often needs several rows with an owner for each. The 5 deal-breakers in 5.2.2.6 should be verifiable end to end before anything else is marked done.
Step 3 — test with real questions, including awkward ones
Build a test set from questions your customers genuinely ask, then add the cases the standard names: a customer who explicitly asks for a person, a question touching information security, a question about something time-critical, and a question the system will not understand no matter how it is phrased.
Run each one and record what the system does. The purpose is not to score the AI's answers — it is to observe whether the handover behaves as required.
Step 4 — record what you cannot satisfy, and why
A gap register is the deliverable of a self-check. Each row should carry the requirement, its clause, the observed behaviour, the reason for the gap, and the risk if left alone.
Be explicit about which gaps are configuration problems and which are product limitations. They have different fixes: the first you change, the second you either work around or change vendor over.
Step 5 — fix, retest and keep the evidence
Prioritise by customer risk rather than by ease. A missing handover on an information security conversation outranks a slightly slow response on a routine question.
Then retest against the same test set and keep both results. The before-and-after is what turns a self-check into something you can show — to a customer, a platform, or a reviewer asking how the requirement is met.
📄 Printable self-check checklist (free)
The 61-item checklist above is available as a single A4 page you can print and hand out:
View the one-pager ｜ Download PDF (one A4 page)
Prefer to tick the boxes yourself? Use the online self-check tool and get a gap report.
Key facts
| Method | Five steps: read, locate, test, record, fix and retest |
| Starting point | Chapter 5.2 (handover) rather than chapter 1 |
| Deliverable | A gap register with clause references and before-and-after test evidence |
| Common first finding | A handover setting that exists but is disabled or left at an unexamined default |
| Self-check checklist size | 61 items = 48 shall + 4 should + 9 may, including 5 deal-breakers |
| Priority | Clear the 48 shall items first; should and may come after |
Sources
- GB/T 47746—2026, clause 5.2 (handover requirements, both directions)
- GB/T 47746—2026, clause 5.2.2.6 (scenarios to include in the test set)
Follow-up questions
How long does a self-check take?
For a small business running a single AI customer service channel, the read-and-map steps can be done in a working session; the testing step depends on how many real questions you can assemble. The work is not long — the discipline is in recording gaps honestly rather than declaring compliance.
Do I need a consultant?
No, but do not skip step 4. The failure mode of a do-it-yourself self-check is not incompetence, it is optimism — a gap that was noticed and quietly not written down. A reviewer's most useful question is simply to ask for the gap register.
What if my vendor says their product is compliant?
Ask which specific requirements their product implements and where the setting is. Compliance is a property of your configured service, not a badge on a product page — and the configuration is what the customer experiences.
Published by SavantCat · source https://savantcat.cn/en/answers/ai-service-standard/how-to-self-check.html · please keep the attribution when quoting.