On Monday morning, a small advisory firm activated a generative assistant to answer the first questions from clients. The decision came from a familiar scene: two members of the team spent much of the day searching for email models, summarizing tax updates, and sorting documents before they could give a useful response. The demonstration promised to save those opening minutes. By mid-afternoon, an adviser had pasted into the tool a message containing identification numbers and details of a business separation. No one knew whether those data could be used, whether they would be retained, or who had to review the draft before it was sent. Speed had arrived before agreement.
The problem is not that the team wanted to try a tool. The problem is treating preparation as a dispensable delay. An assistant may seem harmless because it produces text in a familiar window, yet it intervenes in data, professional judgment, client relationships, and decisions that someone will later have to defend. Saying “we will learn as we go” distributes those decisions among people with different urgencies and unequal power to stop anything. Shared responsibility begins before the first prompt: it means agreeing which conditions make a trial reasonable and which conditions require not starting it.
Preparation describes work; it is not a form to complete#
The firm needs to begin with the specific tasks it hopes to improve. It is not enough to write “use AI for productivity.” It should distinguish between locating a public rule, summarizing an internal meeting, preparing a response draft, calculating a recommendation, and communicating advice that a client will use to make a decision. Each task combines different risks. A summary of published guidance is not the same as text containing employment data, and an internal suggestion does not carry the same effect as an answer sent under the firm's signature.
The firm needs to begin with the specific tasks it hopes to improve. It is not enough to write “use AI for productivity.”
A readiness record can make that difference visible without becoming bureaucracy. For each proposed use, it should note purpose, people affected, data that might appear, plausible error, necessary review, and the person responsible for deciding whether to test it. For client responses, the entry might state that the assistant prepares structure and clear language only; it does not interpret private documents, calculate obligations, or send anything. That boundary gives an operational instruction rather than a values statement. It also reveals when a task presented as administrative actually has a professional consequence requiring a different route.
The record must name information that never enters. The firm cannot rely on everyone remembering a long list when they are rushed. It can define straightforward categories: personal identifiers, client files, credentials, unpublished contracts, and third-party data received in confidence. When a case requires that material, the route is not “try it carefully,” but an authorized environment or work without the assistant. A boundary becomes stronger with real examples: an account number is not safely replaced with an asterisk if the surrounding context still identifies the person; an internal report is not harmlessly pasted in fragments if the fragments can reconstruct it.
Training changes with the role using the tool#
A general session on writing prompts is not enough. The person preparing text needs to learn to separate facts supplied by a client from sentences suggested by the tool and to notice when a persuasive tone hides an unverified claim. A document reviewer needs to know when an answer requires a primary source. The person managing accounts needs to understand permissions, retention, vendor access, and how to remove an integration. Leadership, meanwhile, must understand that approving the tool includes reserving review time and accepting that some early gains will disappear if problems emerge.
Role-based training becomes more useful when it uses uncomfortable situations. The team can practice a query mixing a public fact with a confidential note, a client asking for an immediate answer, and a draft that confidently cites a rule that does not exist. The question is not only, “Which button should I press?” It is: which part can be prepared, which part must a person check, and how can a delay be communicated without inventing certainty? Rehearsing those decisions before pressure arrives keeps the response from depending on the courage of the least experienced person.
There should also be a route for saying, “I do not know.” If someone finds that the assistant used data it should not have used or offered a doubtful conclusion, they need a channel that does not require them to resolve the incident alone. The channel should say whom to notify, what information to preserve, and what not to do, such as forwarding the content to more people in search of an opinion. Training fails if it teaches a feature but does not grant social permission to pause when that feature behaves unexpectedly.
A sandbox discovers limits; it does not certify enthusiasm#
Before connecting the assistant to real work, the firm can set up a test environment using materials created for that purpose: fictional files, public rules, simulated emails, and cases where the correct answer includes acknowledging missing information. The sandbox should resemble the work closely enough to reveal failures, but it must contain no real client data. Its purpose is not to achieve a brilliant demonstration. It is to learn how the tool fails, what kinds of instruction induce errors, and how long it takes a person to detect and correct a draft.
During the test, each role should record a small number of comparable observations: the task attempted, the output received, the correction made, time required, which data would have been risky to include, and whether the reason for the result was understood. That log exposes things a satisfaction survey hides. The assistant may save five minutes on repetitive writing yet add twenty when a rule changes. People who know the subject best may spot failures, while newer colleagues trust fluent answers. Those differences help determine the scope; they are not evidence for blaming whoever found them.
The sandbox needs a closing date and a review with the power to change the plan. If it becomes a permanent test, exceptions become normal and no one knows what has been learned. At the end, the team can limit use to one task, redesign the safeguards, change vendor, or choose not to proceed. The reasons deserve to be recorded, because six months later it will be tempting to remember only the promises from the original presentation.
Passing, pausing, and withdrawing are different decisions#
The firm needs public criteria for moving from a trial to limited use. It can require that test materials contain no prohibited information, that each role has completed its training, that human review has an assigned person, and that known incidents have a response route. These are readiness thresholds, not a guarantee that failure will never occur. Their purpose is to stop commercial pressure from turning an intuition into a practice before minimum conditions exist to sustain it.
Pausing differs from withdrawing. A pause is for behavior that needs investigation: the assistant blends sources, exposes an unexpected integration, suddenly increases corrections, or produces answers the team cannot justify. It should specify which use stops, who tells staff, how tasks are handled in the meantime, and which evidence is reviewed. Withdrawal means the risk or repair cost is no longer proportionate to the benefit, or the vendor cannot provide a verifiable correction. Both possibilities should be planned before procurement, not negotiated in the middle of an incident.
The next time someone proposes turning on the assistant “just to try it,” the firm can open the readiness record and ask precise questions: which task are we supporting, what information stays out, who reviews this kind of text, where is it tested, and what signal makes us stop? If those questions have no answer, waiting is the responsible action. If they do, the team has not removed risk, but it has distributed the ability to recognize and act on it. That distribution prevents a tool's speed from becoming the only clock governing a profession.
