Define the task and its boundaries
Describe what the tool should help with, who uses it and which decisions stay with people. Identify prohibited uses and information that must not be entered. Assign an owner to approve changes and answer acceptable-use questions. A vague approval to experiment can become broad operational permission by accident.
Begin with a limited, lower-impact workflow and suitable test information. Define success and failure before the trial, covering accuracy, confidentiality and consequences rather than speed alone. Include examples where the expected answer is to stop or ask for review, not generate a plausible response.
Check the vendor and actual configuration
Review terms for the specific product, subscription and account type. Check retention, model-training use, deletion, subprocessors and relevant data locations. A general marketing statement may not describe an optional connector or a personal subscription. Obtain clarification where an important condition remains ambiguous.
Examine administration, account security and connector permissions. Identify who can enable integrations or change settings. Involve privacy expertise where personal data is used, including whether a UK GDPR impact assessment is required. This is not legal advice and supplier assurances do not establish lawful use on their own.
Limit access and retain meaningful oversight
Give only the permissions and data needed for the task. Prefer read-only access where suitable and avoid broad shared credentials. Sending messages, changing records or executing code is a separate capability requiring explicit review. Do not let an initial drafting trial quietly gain operational write access.
Put approval before consequential actions and give reviewers context to challenge recommendations. Oversight is weak if people approve routinely without checking. Enforce restrictions through application design and permissions, not only prompt instructions. Test whether a rejected action stays rejected through alternative paths.
Prepare for mistakes and changing behaviour
Explain reporting for inaccurate output, disclosure and unexpected actions. Identify who can disable a connector, revoke access or pause the workflow. Test these arrangements before dependence develops. Keep useful information about the event without further circulating the exposed material.
Review after model, terms, connector or purpose changes. Retain significant decisions and incident lessons. A successful pilot does not establish that every future use is acceptable. Compass is available now; these recommendations imply no specific adoption-management functionality.