A powerful model helping someone draft a private note can have a small impact. A simple agent changing shared records or sending customer messages can have a large one. The model’s capabilities alone do not tell me how much governance its use requires.
I start with blast radius: the potential reach and consequences of an error, misuse, disclosure or unauthorized action. My proposed approach is to keep bounded personal experimentation simple and increase scrutiny as authority, exposure and consequences grow.
This is a governance proposal. It assumes existing platform, data, security and business controls remain in force. “No additional review” means no separate review for that particular AI solution within an already authorized scope.
Check the boundaries first
Before considering who will use a solution, I ask whether it stays within approved data access, authority, impact and safeguards. An expansion needs review. Unknown facts need clarification.
That first check matters because personal use is not necessarily low-impact use. An agent operated by one person can still send bulk messages, alter shared records or commit funds. Limiting access to its creator does not authorize those consequences.
Separate personal use, direct sharing and broad deployment
Within established boundaries, I would distinguish between solutions configured inside an approved platform’s existing capabilities and safeguards, and custom solutions that introduce capabilities or safeguards someone must separately design, operate and assure.
The distinction is responsibility. Writing code is not, by itself, the deciding factor. A separate runtime or an integration outside existing assurance can introduce obligations that configuration within an approved platform does not.
| Who will use it? | Within approved platform capabilities | Custom capabilities or safeguards |
|---|---|---|
| Only the creator | No additional review | No additional review |
| Intended recipients, shared directly | No additional review if the conditions below hold | Review required |
| Broad or automatic distribution | Review required | Review required |
Every row assumes the initial boundary check has passed. Where review is required, its depth follows the actual blast radius.
Direct sharing needs clear responsibilities
I think of direct sharing as borrowing a colleague’s tool. Recipients deliberately adopt it and remain responsible for how they use it. For that to work:
- Access is limited to intended recipients who understand the purpose, limitations, permissions and actions.
- Each recipient uses their own authorized access. Sharing a tool does not share its creator’s credentials or permissions.
- The creator maintains the configuration and communicates limitations; recipients check outputs and actions in their own use.
- Sharing does not imply organizational endorsement or bypass publication controls.
If the facts are unclear, clarify them. If these conditions are not met, treat the distribution as broad. The relevant question is who can actually access and adopt the tool, rather than which sharing button was clicked.
Assess what could go wrong
I use six questions to assess blast radius:
- Reach: who could be affected or rely on the result?
- Authority: can it read, draft, send, change records, spend or make consequential decisions? What gates execution?
- Data: whose data is involved, how sensitive is it, and where can it go?
- Consequences: what harm could follow from an error or misuse?
- Containment: who can detect problems, stop execution, reverse actions and recover?
- Propagation: how often can it run, and can its effects spread to other systems or agents?
Bounded, reversible use with limited exposure may need only a lightweight check of ownership, permissions and containment. Shared operational effects, sensitive data or repeated writes call for workflow assurance: failure testing, monitoring, recovery and maintenance ownership. Severe consequences or difficult reversal warrant formal review by the relevant business and specialist owners.
The most consequential exposure should guide the depth of review. A severe risk should not disappear inside an average score. These are guides for proportionate assurance, not automatic approval thresholds. Review may require tighter boundaries, stronger controls or rejection.
A human approval button is not an exemption
Human oversight helps when the person can understand, stop or correct the consequential action. An approval button that encourages routine acceptance provides little assurance.
I therefore assess the effectiveness of oversight alongside the system’s authority and impact. The presence of a human does not eliminate the need to understand what the system can do. This builds on my argument in Responsible AI: Enhance Human Judgment, Don’t Replace It.
Approve a scope that can be reused
Record the owner, capabilities, audience, data, authority, scale and safeguards covered by approval. Then allow reuse within those boundaries.
Review again when the scope materially expands or essential safeguards change. Routine prompts and executions should not restart the approval process. A model change matters when it changes the risk or falls outside existing assurance.
My aim is governance that allows capability and learning to spread while concentrating attention on consequential exposure. That supports the distribution of AI capability without confusing access to a tool with authority to affect others.