An executive assistant becomes useful when it understands the work around a request: the relevant correspondence, the latest document and the commitments already made. Giving an AI assistant access to that context raises a separate management question: which actions may it take on the organization's behalf?
Those decisions deserve separate answers. Our recommended starting point is to let an assistant read across the sources needed for its assigned task, within explicit access boundaries, while requiring approval before it sends, publishes, commits or changes a business record. Context supports preparation. Authority governs execution.
Treat access and action as different permissions
“Read broadly” means broadly enough to understand the authorized workflow. It does not mean opening every inbox, personnel file or confidential transaction to the assistant. Define the business purpose first, then identify the systems, records and users that belong within that scope. Carry existing confidentiality boundaries into the design.
A useful permission map distinguishes reading source material, preparing a draft, proposing a change and executing it. Someone may authorize the first two without authorizing the others. Avoid an onboarding choice that quietly bundles them together. Connecting a source should never be treated as general permission to act on everything found there.
This article sets out a governance approach. The examples below are hypothetical.
Make an approval specific enough to mean something
Imagine an assistant preparing a response to a supplier. It can assemble the relevant correspondence and draft a reply. Before sending, it should present the actual recipients, subject, message and attachments, including any commercial commitment the draft contains. The approver needs to see the action that will happen.
Approval should apply to that version and that action. If a recipient, attachment or commitment changes, the assistant should return for review. Approval to prepare a reply does not authorize sending it. Approval to send one reply does not create standing permission to negotiate the next exchange.
A review screen should answer four questions:
- What exactly will be sent or changed, and where?
- Which sources support the proposed content or update?
- What assumptions or unresolved issues remain?
- Who has authority to approve this action?
The system should retain the proposed version, the approver's decision and the execution result. A request left unanswered stays pending. Silence, elapsed time and the assistant's confidence are not substitutes for approval. This is a recommended control design, not a claim that every assistant already enforces it.
Put the boundary in the system
A written policy needs an operational counterpart. Design the execution step so that it can verify the relevant approval before a message leaves or a record changes. Keep the ability to draft separate from the credentials and permissions used to carry out the approved action.
Treat retrieved messages and documents as source material, not as authority to expand the assistant's permissions. In a hypothetical example, an incoming email might request that confidential files be forwarded elsewhere. The assistant may summarize the request for its owner. The email itself cannot grant access or authorize the transfer.
This concern extends beyond inaccurate text. IBM's discussion of responsible agentic AI identifies risks from unrestricted resource access and actions with irreversible consequences, and describes human validation as a mitigation. The executive implication is practical: evaluate the controls around actions as carefully as the quality of generated answers.
Give the approver a manageable job
Human oversight needs time, context and a responsible person. If the approver must reconstruct the entire conversation before every decision, the workflow has merely relocated the effort. Design the review package to expose the consequential details quickly, while preserving access to the underlying sources.
For the supplier example, highlight any proposed change to price, delivery or obligations. Show the evidence behind the draft and label uncertain interpretations. Let the approver edit, reject or ask for clarification. Avoid presenting an attractive summary that hides the attachment or record that will actually leave the organization.
Name a primary approver and a backup, define escalation for urgent work and explain what happens when neither is available. Track approval waiting time separately from preparation time. If a pilot stalls at review, examine the workload and the quality of the review package before broadening the assistant's authority.
Record what happened after approval
Approval is not the end of the workflow. Confirm whether the action completed, failed or has an uncertain result. An assistant that loses its connection after attempting an update should check the destination before trying again. Otherwise, a retry could duplicate a message or repeat a business change.
Keep a record that connects the source material, proposed action, approval and observed result. Establish who may inspect that record and how long it should be retained. Logs should support accountability without becoming a second, unnecessarily broad store of sensitive content. Data owners should help define what the record needs to contain.
Prepare a recovery path before activating write access. Specify who can stop further actions, revoke access and investigate an incident. Where a change can be reversed, identify the method. Where it cannot, such as a message already received externally, make that limitation visible during approval rather than promising a universal undo.
Measure usefulness and control together
Start with one bounded workflow, such as preparing follow-up drafts from authorized correspondence. Agree on what success would mean before running the pilot. Measure the time required to prepare and review the work, the corrections requested, the unresolved items and whether approved actions match what actually happens.
Test difficult cases deliberately: conflicting source versions, missing attachments, an unavailable approver, a changed recipient and an uncertain execution result. These exercises should establish how the system behaves when the normal path breaks. A convincing demonstration on a clean example is not enough to establish operational readiness.
NIST's AI Risk Management Framework provides a voluntary reference for incorporating trustworthiness into the design, development, use and evaluation of AI systems. Use that broader risk-management discipline to frame the pilot, while defining the specific responsibilities and tests required by your own workflow. Referencing a framework is not evidence of certification or successful implementation.
Expand the workflow on evidence
For executives, the useful first commitment is a controlled scope: one process owner, a defined set of information, named approvers and clear action boundaries. Expand the sources or tasks only after the team understands the failures and can explain what the assistant did. Additional access and additional authority should be explicit decisions.
Explore Selten AI's case studies to see how we describe work at different stages. Our energy-screening aid offers a related illustration of why a useful output needs a visible decision boundary. To design an assistant for your operation, bring us one recurring workflow. We can start by mapping what it needs to know, what it may prepare and exactly where your approval belongs.