Roll out AI tools without handing over client secrets

Start with one use and a data owner

Choose a specific activity, such as drafting a generic troubleshooting article from public documentation. Identify the business owner, technical reviewer and person authorized to approve the input data. Separate tool administration from authority to disclose client information.

This guide provides general operating guidance, not legal, compliance or insurance advice. Client agreements, regulated data, processing terms, international transfers and notification obligations need review by the appropriate qualified adviser and responsible client representative. A checked settings sheet does not establish compliance.

NIST's generative-AI profile identifies leakage and unauthorized use of sensitive data as risks.^[3] Use that as a reason to map the data flow. The questions below are a proposed operating checklist; they are not a claim that every vendor provides the same controls.

Classify what goes into the prompt

Apply your existing data-classification policy where one exists. If it does not, agree a simple temporary boundary with the responsible owner before the pilot. The following categories are suggestions, not a substitute for a client-specific policy.

Input class	Example	Suggested pilot boundary
Public	Published vendor documentation	Permitted in the approved tool; check licence and relevance before reusing output.
Internal, non-sensitive	Generic procedure without client details	Permitted only after its owner checks content and destination.
Client confidential	Ticket text, topology, commercial terms	Excluded by default; a specific approved use needs data minimization and the client's authorized route.
Restricted or secret	Credentials, recovery codes, private keys, sensitive incident evidence	Do not enter secrets into prompts; keep restricted evidence out of this pilot and use the approved secure process.

Do not rely on the document's title. A generic-looking attachment may contain screenshots, names or hidden notes. Check the content. Replacing a client name does not remove a distinctive address, system identifier or quoted email that can identify the client.

For a service-desk use, specify the permitted fields rather than allowing the whole ticket. Use fictional records for initial testing. If a real case cannot be minimized without losing necessary meaning, leave it outside the approved scope until the responsible reviewer resolves the boundary.

Check the exact tool, plan and account

Record the product, subscription, account type and tenant or workspace you actually use. Read that combination's current documentation. Save the URL, fetch or review date, relevant statement and settings evidence in a restricted review record. Do not treat a personal account and an organization-managed account as interchangeable.

Check each item below; record unavailable or unknown controls rather than assuming they exist:

Whether inputs and outputs are used for model training, and what exceptions or opt-in choices apply.
Retention, deletion and history behavior for conversations, uploaded files and provider logs.
Who in your organization and at the provider can access content, and under what support or review process.
Identity, MFA, administrative roles and the route to remove a departed user's access.
Sharing defaults, public links, guest access and export controls.
Connected search, agents, plug-ins and integrations: data destinations, permissions and possible write actions.
Processing locations, subprocessors and contractual terms that the qualified reviewer needs to assess.
Audit events, available logs, retention controls and the limits of monitoring in your subscription.

Microsoft's enterprise-data-protection documentation says the applicable controls vary with the underlying subscription.^[4] It also describes separate data-handling practices for Bing web queries and tells organizations to check agents' own privacy statements and terms.^[4] That is a concrete reason to inspect connected features separately. It does not establish the behavior of another vendor, another plan or every feature bearing an AI label.

A statement that prompts are not used to train a foundation model answers one question. It leaves retention, access, sharing and connected data flows to be checked. Record evidence for each rather than writing a single "private" tick.

Make approval narrow enough to follow

Keep an approved-use list with one entry per activity. Include the permitted account, input class, output destination, reviewer and excluded actions. An entry for public KB drafting must not silently authorize client-ticket processing or mailbox access.

Set an expiry or a review trigger. Product changes, new connectors, changed terms and new data categories should reopen the review. Give staff a place to request another use without making an urgent ticket the experiment.

Test the boundary with fictional data: a permitted prompt, a deliberately excluded attachment, a sharing attempt and a connector request outside scope. Verify that staff can find the approved account and report a mistake. Where the product cannot enforce a limit, record the reliance on procedure and decide whether that is acceptable for the proposed use.

Do not connect everything because it is convenient. Start without operational-system write access. Approving a writing tool does not approve an agent to change RMM policies, disclose documents or send messages to clients.

Give staff a short note, not a policy hunt

The staff note should answer what they can do today. Name the approved use and account, list prohibited inputs, explain required review and identify the person to contact before trying something new. Link to the fuller policy for context.

For a draft-only service use, require the person handling the ticket to check facts, client identity and promises before output goes into an operational record. The service-desk AI guide provides acceptance checks and a correction-rate definition. Neither approval nor good previous output removes that review.

If staff paste excluded information, they should stop the affected use and report it through the existing incident route. Preserve a safe reference to the event. Do not ask them to paste the exposed secret again into an email, chat or incident summary. The incident owner decides containment and further action under the approved process.

Log the decision without creating another disclosure

Keep enough evidence to reconstruct use and review: user or role, use-case ID, tool/account, timestamp, data class, source-record reference, output destination and acceptance result. Treat retained prompts and outputs as potentially sensitive. Choose restricted storage and an approved retention period; do not copy every client conversation into an unrestricted monitoring sheet.

Automate checks that support the agreed policy, such as reminders when an approval expires or reports of newly enabled connectors where your tools expose that evidence. A person still approves scope, interprets unusual activity and handles an incident. Test the alert recipient and pause route before relying on them.

Review corrections and exceptions alongside effort. Remove unused connectors, standardize the approved uses, and only then automate their repeatable checks. Extra administration can produce a zero or negative capacity result. Keep the work needed for oversight in any hiring discussion.

The working discipline

Automate before you hire

Standardize approved uses, data classes and account boundaries before automating approval-expiry or connector-change reminders. People retain authority over client-data use, output review and incidents; extra oversight may consume rather than release capacity.

Review the sequence →

Worksheet / Usable takeaway

AI approval sheet and staff-use note

Use-case ID and purpose: [one activity / expected outcome].
Authority: [business owner / data owner / qualified reviewer where needed / approval date].
Approved tool: [product / plan / organization account / tenant or workspace].
Input boundary: [permitted classes and fields / prohibited inputs / redaction method].
Data-flow evidence: [training / retention / access / sharing / connected features / URLs and review dates].
Unknown or unavailable controls: [gap / consequence / owner / decision].
Output boundary: [destination / required human check / excluded actions].
Monitoring: [events or references retained / storage access / retention / alert owner].
Validation: [fictional test cases / observed results / pause and reporting route checked].
Review trigger: [expiry / product change / connector change / new data category].
Staff instruction: use [approved account] only for [activity] with [permitted inputs]. Never enter credentials or client secrets. Keep [excluded data] out. Check [facts and approval requirements] before using output.
Staff escalation: ask [owner / route] before a new use. If excluded data enters the tool, stop [affected activity] and report through [incident route] using a safe reference, not another copy of the data.
Remaining human work: [approval / output review / incident handling / capacity effect].

Open the worksheet: AI approval sheet and staff-use note Download (Markdown)

Sources

Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile

Enterprise data protection in Microsoft Copilot and Microsoft Copilot Chat

Source notes: Oct 2026. See method and evidence notes.