AI Governance Needs Shared Rules and Different Controls

A shared AI policy is useful. A shared approval workflow for every use of AI is harder to defend.

Consider a hypothetical public library. One assistant answers questions about opening hours from the public website. Another drafts replies using a member's borrowing history. Both produce text. Neither can change a database. Yet the second can expose information the first never sees. Calling both "read-only assistants" hides the difference that matters.

Now give the first assistant permission to publish closure notices on the library's website. Its model has not changed, but its authority has. An incorrect answer to one reader and an incorrect notice to everyone deserve different controls.

These are invented examples, not accounts of a deployment. They illustrate the problem with assigning governance by agent name or broad task category. The useful unit is a particular use, with particular data, permissions, and consequences.

Keep a common floor

Differentiated governance does not mean letting every team invent its own rules. I would keep shared requirements for a named owner, an inventory of deployed uses, access control, incident reporting, and a way to withdraw a capability. Applicable legal and privacy obligations do not disappear because a team calls its assistant low risk.

The controls above that floor can differ. A public-information assistant might need source freshness checks and sampled answer review. An assistant handling borrowing records needs restrictions on which records it can access and where its output can go. A publishing assistant needs a policy for who may authorise a notice, plus a correction process when something wrong goes live.

Those controls address different failure paths. Asking a person to approve every public-hours answer would consume attention without necessarily checking the more consequential problem: whether the source itself is out of date.

This distinction is compatible with the NIST AI Risk Management Framework. GOVERN 1.3 calls for processes that determine the needed level of risk management based on organisational risk tolerance. GOVERN 1.6 addresses inventories resourced according to risk priorities. The framework also provides use-case profiles for particular settings [1]. It offers guidance for tailoring risk management, not evidence that one workflow fails everywhere.

Classify the use before debating the tier

Tier names can make an unsettled decision look settled. "Medium risk" tells a reviewer little unless it comes with an explanation of what could go wrong.

For the library's member-correspondence assistant, I would begin with a short description: it may retrieve records for the authenticated member, draft a response for an authorised librarian, and show that draft only in the staff workspace. It may not send messages or retrieve another member's records. The potential harms include disclosure and misleading advice, even though it has no write access.

That description creates questions a team can test. Does record access enforce the member boundary? Can a generated answer include information from a different conversation? Can the draft be copied into an external channel without a further check?

A useful classification should record:

• The intended use and the people who could be affected.
• The data available and the actions the system can actually take.
• The consequences of an error, including exposure that cannot be undone.
• The evidence supporting the proposed controls and the uncertainty left over.

These are inputs to a decision, not numbers to multiply into a supposedly objective risk score. A familiar task can still involve sensitive data. A reversible database update can still cause an irreversible disclosure. A successful test history can support a narrow permission without justifying broader access.

NIST's MAP 1.1 asks organisations to document intended purposes, deployment settings, assumptions, and potential impacts. MAP 2.1 asks them to define the tasks the system will support [1]. The library description is my practical application of that guidance, not a NIST-prescribed template.

Give the disagreement an owner

The hard part often arrives when a control makes a useful feature slower. The product team wants the correspondence assistant to send replies directly. The privacy reviewer wants staff to check each one. Both are responding to something worth protecting.

The governance record should make that disagreement explicit. What extra harm could direct sending create? What evidence would support a limited trial? Who can accept the remaining risk, and who can stop the trial?

Assigning those decisions to "the human in the loop" is too vague. The librarian checking a reply may be able to spot a factual error but may have no authority to approve a new data use. A workflow owner needs to own the control design; an authorised decision-maker needs to accept residual risk within their remit. Reviewers need access to evidence and permission to reject an action.

GOVERN 2.1 addresses clear roles, responsibilities, and communication. GOVERN 2.3 places responsibility for development and deployment risk decisions with executive leadership [1]. A signed approval should not quietly transfer an organisation's obligations to whichever operator happened to be on duty.

And approval can be wrong. Access restrictions and destination checks should still apply after someone approves a draft.

Ask what the controls actually catch

Counting completed reviews is easy. Finding out whether the reviews work takes more care.

For the hypothetical library, a test could present conflicting opening-hours entries and check whether the public assistant flags the uncertainty. A separate test could ask the correspondence assistant for another member's history and verify that access is denied. Neither test establishes safety in general. Each tests a stated control against a stated failure.

For sampled answer review, record how the sample was selected. For disclosure tests, record which access paths were exercised. Report missed errors as well as caught ones. A high approval rate could mean proposals are good, reviewers are overloaded, or the sample contains only easy cases. It cannot distinguish those explanations on its own.

Keep results separated by use and consequence. An aggregate score dominated by routine public questions could conceal weak handling of member records. NIST MEASURE 1.2 calls for regular assessment of both metrics and the effectiveness of controls [1]. That is a better basis for a review meeting than the number of boxes checked.

Reopen the decision when the use changes

The member assistant's original assessment stops fitting when someone adds an external sending tool. The public assistant's assessment stops fitting when it starts using non-public documents. A change in audience can matter as much as a new model.

Write these triggers into the record before launch. A broader recipient group, new data source, or expanded permission should prompt reassessment of the affected use. Routine changes within the assessed scope need not restart the entire governance process, but someone must decide what counts as remaining within that scope.

The next governance review should be able to answer a concrete question: why is this assistant allowed to do this action with this information today?

If the answer is only "all our agents follow the policy," the team has more work to do.