Every team using AI in testing already has a policy — unwritten, inconsistent, and discovered one incident at a time. This playbook drafts the written version: one signable page covering where AI-generated tests are allowed, which review gates are mandatory, what data may enter which tool, and how AI use appears in audit trails.
Tier: Core · Workflow area: Quality leadership & governance
You will draft the policy with AI against NIST AI RMF and ISO/IEC 42001 as reference frames, pressure-test it with the people it binds, and ship it as a page a director will actually sign — because a policy nobody signs is a blog post, and a policy nobody can read in five minutes is a shelf ornament.
Your team already uses AI on test artifacts and every engineer has invented their own rules. A client or auditor asked "what is your AI policy?" and the honest answer is a shrug. An incident happened — client data pasted into a public chatbot, an unreviewed AI suite merged — and leadership wants guardrails. Certification against ISO 42001 or alignment with NIST AI RMF is on the roadmap.
The org has a corporate AI policy that genuinely covers testing specifics — write the one-page testing annex instead of a rival document. Nobody uses AI yet and there is no adoption plan — write the policy alongside the first pilot, not before it, or you will regulate imagined behavior.
Inventory reality first. Fifteen minutes per team lead: list every AI tool touching test work (IDE agents, chatbots, self-healing platforms, judge evals), what goes into each, and what comes out into which repo. This inventory becomes the policy's scope section and almost always contains at least one surprise worth a same-week fix.
Draft with AI against the reference frames — structure in, boilerplate out.
Draft a one-page AI-testing policy for a QA organization of ~40
engineers at a services company with client codebases.
Structure — exactly these six sections, max 5 bullets each:
1. Scope: which testing activities AI may assist (and which not)
2. Mandatory review gates: what human review each artifact type
requires before merge/filing
3. Data rules: what data classes may enter which tool tier
(approved-enterprise / local-model / prohibited)
4. Disclosure: how AI assistance is recorded in commits, test
artifacts and client deliverables
5. Accountability: who owns an AI-generated artifact after merge
6. Exceptions: who may approve one, in writing, for how long
Constraints: fits on one page. Every rule enforceable by a
reviewer without special tooling. No aspirational language
("strive", "endeavor"). Align terminology with NIST AI RMF
(govern/map/measure/manage) and ISO/IEC 42001 so an auditor can
map sections to controls, but do not cite chapter and verse
inline. Where I must make a local decision, insert
[DECISION: options A/B] rather than choosing for me.
The [DECISION] instruction is the important one — the model drafts structure and phrasing fast, but every actual rule (which tools are tier-1, whether AI-generated tests may cover payment code) is a human call the draft must force you to make visibly.
Make the data rules a decision tree, not prose. The section people will actually consult under deadline pressure must be scannable:
Data class -> Approved tier -> Rule
Public / synthetic -> any approved tool -> go
Internal code/tests -> enterprise tools -> no consumer chatbots
Client code -> client-approved -> check engagement letter
PII / secrets / keys -> local model only -> after masking (see
pb-25); never SaaS
Set review gates per artifact risk, not blanket. A single "all AI output needs review" rule is either ignored or throttles everything equally. Tier it: AI-generated test cases → peer review against the coverage rubric before entering the suite; AI-authored automation code → normal PR review plus assertion-strength check; self-healed locators → audit-queue approval (pb-18); AI-drafted defect reports → reporter verifies repro personally before filing; judge verdicts → may not gate releases without a current calibration report (pb-40). These cross-references turn the policy into an index of your playbooks — enforcement becomes "follow the linked recipe."
Pressure-test with the people it binds. One-hour review with 4–6 engineers: for each rule ask "what would make you bypass this on a bad Friday?" Every credible bypass story is a rule to simplify or a tooling gap to fix. A rule that requires heroics gets ignored, and an ignored rule on a signed policy is worse than no policy — it converts an incident into a cover-up.
Get the signature and the date — and a review trigger. The signer's name goes on the page. Add a review clause: re-review every six months or upon any of — new tool adoption, client contract change, regulation change, or an incident. Version the policy in git next to the playbooks it references; changes go through PR review like code.
Operationalize the disclosure rule immediately. Whatever disclosure you chose (commit trailers like Assisted-by:, a checkbox in the PR template, a line in test-plan headers), ship the template change the same week. Disclosure that requires remembering is disclosure that decays.
For services companies the client's policy outranks yours. The one-pager needs the precedence line: on client engagements, the stricter of the two policies applies, and the engagement letter's tool-approval list is checked before any AI touches client artifacts.
The policy's power is not the rules — it is that a named person signed one page everyone has actually read, and every rule on it points at a recipe people already follow. Signable beats comprehensive, every time.