Governance: oversight, transparency, and the policy nobody wrote

“A human reviews the output” is only true if a specific person, with the time and the authority to disagree, sees the output before it has an effect. Build the review into the flow so it cannot be skipped under pressure, and log it, because an oversight step nobody can evidence is an oversight step that will be disbelieved.

Distinguish suggestion from decision. A drafted reply a person edits is one thing; a classification that routes a case without anyone reading it is another, and the second attracts a different set of questions in most jurisdictions covered here.

Inwards: staff should know the system exists, what it does with what they type, and what is logged. Outwards: where the system affects other people — clients, candidates, patients, customers — the organisation may owe them information about it, and that obligation is jurisdiction-specific. Read the page rather than assuming.

The cheapest version of this is a short notice next to the tool, written in the organisation’s own words, saying what it can see, what it keeps and who to ask. It prevents more incidents than any technical control.

Two documents cover most of the ground. An acceptable-use policy: which tools are permitted, by whom, on which devices, and what may not be entered into a prompt — the regulator guidance summarised on the jurisdiction pages is explicit about this kind of internal policy. And a register of deployments: what is running, who owns it, what data it touches, when it was last reviewed.

Write both, and make sure the register has a review date on every row. This site marks its own claims stale past a review window because guidance and documentation age; a governance record without a date does the same thing silently.