13.06Research Quality, Ethics and GovernanceAvailable

AI Research Governance

Decide what may be sent to an AI system, record what it did, prove a human checked it, and disclose it usefully.

Free. Works on Claude, ChatGPT, Gemini or any assistant that accepts a skill file.

What this skill does

The method, encoded.

AI arrived in research practice faster than the arrangements around it, and the gap shows up as small ordinary decisions nobody owns. A transcript gets pasted into a system with no decision about whether it may leave the project, whose consent covers it, or whether the client's contract permits it. Coding is rerun weeks later on a different version and produces a different frame, and nobody can reconstruct why.

The cost is rarely a breach. It is that the work becomes unreconstructable, and the moment that matters is when a client asks how a theme was derived or a finding is challenged.

This skill is deliberately operational. Aspirational AI principles documents are abundant and change no behaviour. What changes behaviour is a one-page classification a researcher can apply in ten seconds, a step register that takes a line per use, a sign-off record naming a person, per-code accuracy figures for AI coding, a pinned model version, and a disclosure paragraph somebody has already written.

It covers what may be sent, consent boundaries, the audit trail, sign-off, reproducibility, confidentiality, disclosure to clients and participants, and a seven-section policy short enough to follow.

Best used for

  • Deciding whether specific material may be sent to an AI system
  • Establishing whether existing consent covers AI processing
  • Writing an AI disclosure for a proposal, report or consent form
  • Building an audit trail that makes an AI step reconstructable
  • Governing AI coding and classification including measured accuracy
  • Handling a model or version change mid-project or between waves
  • Writing a research team's first AI governance policy

Typical inputs

What you give it.

Project data inventory with origin and contents, Consent wording in its original form for every participant dataset, Client contractual position on AI, confidentiality and subprocessing, List of project steps that will or did use AI, A named accountable person, Organisational approved-systems list and security position, System data handling terms covering retention, training use, subprocessing and transfer, Model or version identifiers in use, Human-coded comparison sample for AI coding work

Typical outputs

What you get back.

Data classification table with a rule per tier, AI step register recording material, system, version, instruction, date and human check, Consent position by dataset with the decision and who authorised it, Sign-off record naming person, date and what was actually checked, Accuracy record with per-code agreement and the figure to be disclosed, Disclosure text in client, participant and internal versions, Seven-section governance policy with an exception route, Exception log with compensating checks

Method coverage

What the skill works through.

  1. Why governance is about reconstructability, not permission
  2. Classifying material in one table people will actually use
  3. What consent covers, and what silence does not mean
  4. The AI step register, one line per use
  5. Setting the human check, and recording who performed it
  6. Governing AI coding and classification at scale
  7. Measuring accuracy per code, and disclosing the number that matters
  8. Pinning the model version, and why a rerun is not a replication
  9. Handling a version change mid-project or between waves
  10. Three questions to ask of any AI system
  11. Establishing the client's contractual position at proposal stage
  12. Writing a disclosure that says what the AI did and who verified it
  13. A seven-section governance policy, and why it needs an exception route
  14. Auditing the register against the deliverable before delivery

Download

Free skill. One file.

Enter your email once. Every skill you download after that takes a single click.

How to install

Add the skill file and the five kernel protocols to a Claude Project, a ChatGPT Project, a Gemini Gem, or paste them at the top of any assistant conversation. Then give it your real research material, not a description of it.

Download skill

Questions

Common questions.

What can I send to an AI system in a research project?

Decide by material, not by task. Restricted material (direct participant identifiers, special-category data, anything where consent does not cover AI processing, client material under a contractual bar) is not sent at all. Controlled material (de-identified transcripts, open ends, client-confidential material the contract permits) goes to approved systems only, with the step registered. Internal working material and open published material carry lighter rules. Unclassified material defaults to the most restrictive tier, which is what stops the classification being quietly bypassed.

Does our existing participant consent cover AI processing?

If it does not mention it, it does not cover it. The common middle case is consent that refers to processing by the research team or its service providers, which could be read to include it but which a participant would not have understood that way. The options are to re-consent, restrict AI use to steps the consent plainly covers, aggregate so the material is no longer personal data, or not use AI on it. De-identification does not settle it, because the participant's interest includes what reads their words.

What should an AI disclosure in a research report say?

Three things: what the AI did, what a human verified, and by whom. "AI tools were used in the preparation of this report" tells a reader nothing. A useful disclosure names the steps (transcription, coding against a human-approved frame), the verification performed (a stratified sample independently coded, every quote checked against transcript), the measured agreement where coding was involved, the named people who did it, and the sign-off date. Write it from the step register, not from what was intended.

How do I record AI use so it can be audited later?

One line per AI step, filled at the time, kept with the project files: the step, the material and its tier, the system and version, what it was asked to do, the date, who ran it, what human check was applied, by whom, and what the check found. It takes about a minute per step. A register completed near delivery is a reconstruction, and it should be labelled as one, with what is unknown.

Why did rerunning our AI analysis give different results?

Because a different model version, or sometimes the same one, can produce different themes, different boundary classifications and different emphasis. This is a property of the method rather than a defect, and it belongs in the disclosure. The practical rules: record the system and version for every step, pin one version for comparative work, and when a version changes mid-project either finish the affected stream on the pinned version or re-run and re-verify, recording which you did.

Is running an AI analysis twice a form of validation?

No. A rerun tests stability, not correctness, and two agreeing AI passes are one piece of evidence produced twice. Presenting that agreement as corroboration is a traceability failure. Correctness is tested only against source material or against independent human work.

How do I measure the accuracy of AI coding?

Have a human independently code a random sample and compute agreement per code, not overall, because overall agreement hides the failure that matters: rare and boundary codes collapse while the aggregate stays high. Stratify the sample to over-represent rare codes. Then disclose the figure a reader should rely on, which is the worst per-code rate among the codes carrying findings, not the flattering average. Where accuracy cannot be measured, label the output unvalidated and do not let it carry a headline.

What questions should I ask about an AI system before using it on research data?

Three. What happens to the input: is it retained, for how long, is it used to improve the service, can it be deleted, where is it processed. Who else can see it: subprocessors, support access, human review of submitted content. And who owns the output, and could it reproduce material you have no right to publish. A team that cannot answer these for a system it is using has a governance gap rather than a policy debate.

What makes an AI governance policy that people actually follow?

Brevity and applicability. Seven sections: a classification table, an approved-systems list with the tier each may receive, the register requirement, the human check standard mapped to task types, the disclosure standard with pre-written templates, the consent rule, and an exception route with a named authoriser. Every rule names who decides. And the exception route exists deliberately, because a policy with no legitimate way to depart from it will be departed from invisibly.

Do we have to tell clients and participants that AI was used?

Yes, in forms appropriate to each. Participants are told at consent, in plain language, what will process their words and what a human does with the result. Clients get the detailed method statement, ideally established at proposal stage rather than discovered at delivery. The standing professional obligation is not to present AI-assisted work as though it were not, and where a client asks for the disclosure to be omitted from a public document, that is a decision for a named human that does not change the obligation to participants or the internal record.

Research where people already are.
Analyse it where you already work.

Yazi helps researchers conduct surveys, AI interviews and longitudinal research directly through WhatsApp.

New Report on SA Gambling Impact
Check It Out