MyDot Consultancy

Featured image: AI-generated conceptual illustration. Sources checked 26 October 2026.

When someone asks which agents can send customer messages, a business should be able to answer without searching through individual employees’ chat histories. A compact governance register makes purpose, ownership and authority visible. It does not replace detailed technical records, but it gives the organization a reliable index into them.

The register proposed here is an editorial template for practical oversight. It is not a legal compliance checklist or a certification artifact. Use it to make operational questions answerable, then connect it to the reviews and controls appropriate to the business and jurisdiction.

One record for one deployed responsibility

Imagine a hypothetical customer-success assistant that prepares renewal briefings and drafts follow-up emails. Its register entry should describe that responsibility, not simply say “AI assistant.” If a separate configuration can send messages automatically, give that authority an explicit entry or versioned scope change.

Avoid defining the inventory only by model name. Several workflows can use the same model with very different data and permissions. Conversely, one business workflow may use several models. The unit of oversight should be understandable in terms of what the system does and whom it can affect.

The NIST AI Risk Management Framework provides a voluntary approach to incorporating trustworthiness into AI risk management. Its current page notes that version 1.0 is being revised. Treat it as a useful resource while keeping the register tied to the actual deployed system.

Field one: purpose and scope

State the business outcome, intended users and exclusions. “Prepare source-linked renewal briefings for assigned accounts; no contract decisions or autonomous sending” is specific enough to guide a review. “Improve productivity” is not.

Add the current deployment stage: experiment, shadow, reviewed draft or bounded live action, using terminology the organization defines consistently. A prototype should not quietly become production because employees find it useful. Scope changes should be visible and owned.

Field two: accountable owners

Name a business owner who is responsible for the service’s purpose and a technical owner who can maintain or disable it. Include the operational contact for incidents and unresolved tasks. A team mailbox may be useful, but someone should be accountable for keeping the entry current.

Record who approves changes to authority. The person who edits the prompt may not be entitled to authorize new customer-data access or external messaging. Make that decision path explicit so technical convenience does not become an accidental policy change.

Field three: data and destinations

List the source systems and the categories of information the agent may access. Include generated artifacts, logs and any external destinations. A register does not need every database field, but it should point to a detailed data-flow record when sensitive processing is involved.

Note whether the system uses user-scoped access or a service identity. Record the owner of the credentials and the revocation procedure. If the assistant stores conversation history or durable preferences, identify the relevant retention policy rather than leaving memory as an undefined feature.

Field four: tools and authority

Describe allowed actions in business language: read assigned accounts, create drafts, update selected fields, send approved messages or delete specified artifacts. Separate preparation from commitment. A broad label such as CRM access hides too much.

OWASP’s excessive-agency guidance identifies risks from functionality, permissions and autonomy that exceed the task’s needs. Use the register to expose those three dimensions. Link to the actual permission configuration so the written scope can be checked against implementation.

For actions requiring review, identify the eligible approver and the object of approval. “Human in the loop” is not enough. The entry should make clear whether a person approves a particular message, a record change or a broader operating scope.

Field five: evidence and limitations

Link the latest evaluation report, its date and the versions tested. Summarize the covered task categories and known failure modes. A single score without context tells a reviewer little about whether the agent handles missing data, permission denial or partial completion.

The OpenAI evaluation guide recommends task-specific testing and continuing evaluation. A register can keep that evidence discoverable without copying the entire test suite onto one page. It should also make stale evidence visible when the deployed configuration changes.

Write limitations in language users and operators can act on. “Does not verify privately negotiated contract terms” is more useful than “may hallucinate.” State what the system cannot establish and which human process handles that gap.

Field six: change and incident controls

• Current model, prompt and tool versions, or links to their release record.
• Date of the last scope and permission review.
• Triggers for another review, such as a new data source or write capability.
• Location of the cancellation and integration-disable procedures.
• Incident contact and the process for assessing external effects.
• Next review owner and due date.

The register should help someone act during an incident. If an integration is exposing the wrong records, the operator needs to know who can revoke it and what pending tasks depend on it. A governance page that cannot support that decision is mostly documentation theater.

Keep the page small by linking the evidence

Use concise fields and links to detailed records. The one-page goal is navigability, not omission. Store evaluation results, data-flow diagrams and permission matrices where they can be maintained properly, then reference them from the register.

NIST’s AI RMF Playbook offers voluntary suggestions and explicitly says it is not a checklist to follow in its entirety. The same restraint applies here: adapt the template to the actual risk rather than filling fields mechanically and calling the work complete.

Make upkeep part of deployment

Update the register when authority, data, ownership or deployment status changes. Include it in the release process so it does not become an annual exercise detached from the system. Remove or archive entries when a workflow is retired, including its credentials and scheduled work.

A compact register makes accountability easier to find. Its value is not the page itself, but the answers it enables: what this agent does, why it has access, who owns the outcome and what evidence supports its current use.

Sources and further reading

NIST: AI Risk Management Framework. Voluntary risk-management resource; current revision notice checked October 2026.

OWASP: Excessive Agency. 2025 authority and functionality risk categories; checked October 2026.

OpenAI: Evaluation best practices. Task-specific continuing evaluation; checked October 2026.

NIST: AI RMF Playbook. Voluntary suggestions and explicit non-checklist caveat; checked October 2026.