AI at the service desk, with a person checking the work

Give the assistant a limited job

Begin with a draft-only use case. Ticket summaries, categorization suggestions, reply drafts and knowledge-base drafts each have a different acceptance check. Approving one does not approve the others.

NIST describes confabulation as generated content that is confidently false, and identifies over-reliance on AI as a separate risk.^[3] The practical response is to keep the original evidence available and make review part of the workflow. The MSP KB also recommends staff review of AI ticket notes, scripts and configurations before changes are applied.^[5]

Write a short job definition for the assistant: permitted input, expected output, excluded actions and receiving reviewer. If a deterministic template or rule handles the task, try that before adding a language model. Generating prose is useful only when it improves the work after correction effort is counted.

Four uses, four checks

For a summary, require references to the relevant ticket entries where your process can provide them. A reference is something the reviewer must open, not proof by itself. Tell the assistant to mark missing evidence as unknown. Do not ask it to complete an investigation by filling gaps with plausible steps.

Keep a category suggestion separate from priority and assignment. A person still needs to determine impact, confirm the service boundary and accept the handoff. The service-manager routine gives those decisions a place in the day.

A reply draft must not invent a callback time, resolution estimate or approval. For a KB draft, remove case-specific identifiers and retain the limits that made the original fix appropriate. One successful ticket is not evidence that a procedure applies to every client configuration.

Check the input before the output

Use only an approved tool and account for the specific use case. Follow the AI safe-use guide to check data handling, connectors and tenant settings. A business account label does not settle those questions.

Never paste passwords, recovery codes, API keys, private keys or client secrets into a prompt. Do not paste unrestricted client exports, confidential commercial records, personal health information or sensitive incident evidence just because they appear in a ticket. Remove attachments by default until somebody has checked their contents and authority to use them.

Minimize the input to the work needed. A draft explaining a callback does not need the entire mailbox thread. If redaction changes the meaning, stop and ask the approved-use owner for a permitted method rather than guessing at a workaround. Client data belongs only in a use that has been authorized for that data and destination.

Treat ticket text and linked material as evidence, not instructions to the assistant. NIST discusses direct and indirect prompt injection, including instructions delivered through retrieved content.^[3] In this workflow, an embedded request to change permissions or export data receives no authority. Keep tool access outside the draft assistant's scope.

Make review an observable step

Assign the review to the technician handling the work or another named person with the right knowledge. Avoid a generic "human reviewed" checkbox. Record who checked the draft, which evidence they compared and whether they accepted, corrected or rejected it.

The reviewer should inspect the current state first. Has the client replied since the draft was prepared? Did a later entry reverse an earlier finding? A summary of an old ticket snapshot can be accurate for that snapshot and misleading for today's handoff.

Use these checks when preparing a client reply:

• The draft concerns the correct client and ticket.
• Facts come from checked records, and uncertainty remains visible.
• The proposed action fits the authorized service scope.
• Promises have an owner and an agreed basis.
• The message contains no secrets or unnecessary personal details.
• A person approves the final wording and recipient before sending.

Generated commands and configuration changes are outside this draft-only pilot. If a technician proposes using them, route them through the normal technical review, authorized testing and change process. Do not turn a writing assistant into a production operator by accident.

Measure corrections without flattering the tool

Define one unit as one draft presented for review. Exclude attempts that never produced a draft from the correction-rate denominator, but record them separately as failed generation. Unreviewed drafts remain pending and are not counted as accepted.

For this guide's suggested measure, substantive correction rate is the number of reviewed drafts needing a factual or operational correction, including rejected drafts, divided by all reviewed drafts. Cosmetic edits are recorded separately. Count a draft once even when several facts need repair.

A fictional pilot produces 50 reviewed drafts. Eight need substantive correction, including two that are rejected entirely. Its substantive correction rate is 8 divided by 50, or 16%. These are fictional counts, not an expected performance level or an approval threshold. Record what the mistakes were; an average can hide a wrong-client disclosure or an invented resolution.

Also measure reviewer minutes, failed generations and any harm or near miss. The model may shorten writing time while increasing checking time. Use the automation savings calculation to preserve zero and negative net effort results.

Decide whether the pilot belongs on the desk

Before starting, set a scope and end date, name a pause owner and agree what failures require immediate review. Wrong-client content, secret exposure and unauthorized actions should stop the affected use while the responsible person investigates. Handle exposure through the existing incident process; deleting a conversation is not evidence that the exposure has been resolved.

Review error patterns by use case rather than combining summaries and replies into one encouraging total. Change the standard, prompt or scope when the evidence supports it, then test again. Keep people assigned for judgment, queue coverage and client communication. A better drafting workflow is not a staffing verdict.

The working discipline

Automate before you hire

Try templates or deterministic rules first, then test AI summaries and drafts against an agreed acceptance check. A person checks client identity, facts and promises before output is used; include that correction and review effort before claiming capacity.

Review the sequence →

Worksheet / Usable takeaway

Desk AI use-case and review record

• Use case and owner: [summary / category suggestion / reply draft / KB draft / responsible role].
• Scope: [ticket population / approved tool and account / start / end].
• Input boundary: [permitted fields / data classification / redactions / excluded attachments].
• Expected output: [required facts / uncertainty format / evidence references].
• Excluded actions: [sending / production changes / permissions / other tool calls].
• Review: [named reviewer / original evidence checked / current-state check / approval destination].
• Draft result: [accepted / cosmetic edits / substantive correction / rejected / pending].
• Error detail: [missing fact / invented fact / wrong client / unsafe promise / other].
• Measurement: [reviewed drafts / corrected-or-rejected drafts / rate / review minutes / generation failures].
• Stop and response: [trigger / pause owner / manual fallback / incident reference if needed].
• Effort and staffing: [net effort including negative / remaining judgment and coverage duties].
• Next decision: [continue / narrow / repair / stop / owner / review date].

Open the worksheet: Service-desk AI use-case and review recordDownload (Markdown)

Sources

Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile

Operational safeguards and oversight

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