Practice Deciding Whether to Submit Data to an LLM

The cursor is blinking in the paste box. You have a real task, a real dataset, and no rule that clearly says yes or no. This article is a set of reps for that exact moment.

Most people handle that moment one of two ways. They paste on vibes — "it's just an LLM, it's fine" — or they refuse everything sensitive and quietly push their work into shadow tools that nobody approved. Both defaults fail for the same reason: neither one is a decision. They are reflexes.

The skill you actually need is smaller and more boring than a privacy lecture. Four questions, asked in order, producing one of four outcomes. The questions are cheap. The discipline is in refusing to skip one when the answer is inconvenient.

This builds on the earlier guide to classifying data before you send it. Assume you can already look at a field and say "that's a name, that's an account number, that's a public product SKU." What we're practicing here is applying that classification under time pressure, with a task attached and a deadline behind it.

The Four-Question Triage

Ask these in order. The order matters because each question can change what the next one is even about.

Question 1 — What is the most sensitive element? Not the average sensitivity of the document. The single worst field in the payload. One customer email address inside an otherwise public pricing sheet dominates the decision. Scan for the maximum, not the mean.

Question 2 — Does the task require that element? This is the question people skip. Rewriting a complaint email for tone does not require the customer's name, account number, or order history. Extracting structured fields from a contract does require the contract text. Separate what the model needs from what happens to be sitting in the same document.

Question 3 — What controls are actually stated? Not assumed. Stated. What does the product's terms or your organization's policy say about retention, whether inputs are used for training, who can access the data, and where it is processed? "The vendor says it's secure" is not a control. It is a feeling with a brand name attached.

Question 4 — Who is authorized to decide? For this data class, specifically. A policy document, a manager, a legal team, a data owner. If you cannot name the authorizing party, you do not have authorization.

Here is the branch point that trips people up. Minimization changes the payload, so it changes which questions still apply. If Question 2 tells you the sensitive element is not needed, you remove it — and then Questions 3 and 4 apply to what remains, not to the original document. You do not need retention terms for data you are not sending. But you do need them for whatever is left.

The outcomes fall out of the answers:

That last row is the one that matters most. Unknown routes to escalate, not to a guess. An unanswered question is not a soft yes. And notice the boundary between the third and fourth rows: an approved alternative is only actionable when you can name a tool that meets the controls. If you cannot, you are not choosing an alternative — you are escalating a specific unknown.

Scenario 1: The Task That Does Not Need the Data

A support lead asks you to run a customer complaint email through an LLM to rewrite it in a calmer tone. The email contains the customer's full name, account number, and a list of past orders.

Walk the triage.

Sensitivity: high. Names, account numbers, and purchase history are all identifiable.

Task necessity: low. The rewriting task needs sentence structure, emotional register, and the substance of the complaint. It does not need to know who this person is or what they bought last spring. The identity is cargo, not fuel.

So you minimize. Strip the name, replace the account number with a placeholder, and generalize the order history into what the complaint is actually about. Now re-run Questions 3 and 4 on the reduced payload. What remains is a complaint about a late delivery on a replacement part — no identifiers, no account data. For that payload, the controls question is usually answerable and the authorization question is usually already covered by your normal tool-use policy. If it is not, you escalate the reduced payload, not the original.

Here is the trap. People redact so aggressively that the output becomes useless — "Customer is unhappy about something" — and then they go back and paste the original because the minimized version did not work. The fix is to preserve the information the task consumes while removing the information it does not. The complaint is about a late delivery on a replacement part. Keep that. Drop the order number.

Common mistake: Treating minimization as anonymization. Removing a name does not make a record anonymous. A combination of order dates, product names, and a region can re-identify someone. Minimization reduces exposure; it does not eliminate it.

Scenario 2: The Task That Needs the Data

An analyst needs an LLM to extract structured fields — parties, dates, obligations, termination clauses — from a contract that is itself confidential.

Sensitivity: high. The contract is confidential by definition.

Task necessity: high. This is the case where minimization destroys the task. If you redact the parties and the obligations, there is nothing left to extract. The sensitive content is the input.

Now Question 3 does the real work. This is where you stop and read the actual terms instead of trusting the vibe:

• Does the endpoint retain inputs, and for how long?
• Are inputs used for training by default, and can that be turned off?
• Who inside the vendor can access the data?
• Where is it processed, and does that cross a boundary your organization cares about?
• Does an approved enterprise deployment exist for exactly this kind of work?

If the controls are stated and adequate — retention is bounded, training use is off, access is scoped, an approved deployment exists — then submit is a defensible answer. You are not being reckless. You checked.

If the controls are unknown, or the only tool you have is a consumer endpoint with terms you have not read, you have two distinct paths. If you know of an approved tool that meets the controls, use it — that is the approved alternative. If you do not know of one, or you are unsure whether it is authorized for this data class, the answer is escalate. Not "probably fine."

Common mistake: Reading "we take security seriously" on a marketing page and calling it a stated control. A stated control names the specific behavior: what is retained, for how long, used for what, accessible to whom. If you cannot point to the sentence, you do not have the control.

Scenario 3: The Case Where You Must Escalate

A task involves regulated or special-category data — health information, financial records, anything your organization treats as restricted — and the applicable policy is silent or ambiguous.

You check the policy. It does not address this data class for this tool. You check the product terms. They are unclear about retention for this tier.

The correct answer is escalate, and the reason is complete: "I don't know the retention terms for this endpoint, and the data class is restricted." That is not a failure to decide. That is the decision.

Escalation is not refusal. Refusal stops work. Escalation routes the decision to whoever owns the data class, with your triage answers attached so they can decide quickly instead of starting from scratch.

A good escalation is short and specific:

• Data class: what kind of data this is
• Task necessity: why the task needs it, or why it might not
• The unknown: the specific control you could not verify
• Options considered: minimize, alternative tool, delay

Common mistake: Escalating everything. If every task becomes an escalation, the people receiving them learn to skim, and the one escalation that actually mattered gets lost in the noise. Reserve it for genuine unknowns and high-impact cases.

Run the Triage as a Small Classifier

Reading three worked examples teaches you to recognize the author's reasoning. It does not yet test whether you can apply it. So let's make the logic runnable.

The smallest useful version is a function that takes a scenario's answers and returns one of the four outcomes. No dependencies beyond Python 3. Save it as triage.py.

def decide(sensitivity, task_needs_data, controls_stated, controls_adequate,
           authorizer_named, approved_alternative_known):
    # Minimization is possible when the task does not need the sensitive element.
    if sensitivity == "high" and not task_needs_data:
        # Re-check controls and authorization for the reduced payload.
        if controls_stated and controls_adequate and authorizer_named:
            return "minimize"
        return "escalate"

    # The task needs the data. Controls and authorization now decide.
    if not controls_stated or not controls_adequate:
        if approved_alternative_known:
            return "approved alternative"
        return "escalate"

    if not authorizer_named:
        return "escalate"

    return "submit"


scenarios = [
    ("complaint rewrite", dict(sensitivity="high", task_needs_data=False,
        controls_stated=True, controls_adequate=True, authorizer_named=True,
        approved_alternative_known=False)),
    ("contract extraction, approved endpoint", dict(sensitivity="high",
        task_needs_data=True, controls_stated=True, controls_adequate=True,
        authorizer_named=True, approved_alternative_known=False)),
    ("contract extraction, unknown retention", dict(sensitivity="high",
        task_needs_data=True, controls_stated=False, controls_adequate=False,
        authorizer_named=True, approved_alternative_known=False)),
    ("restricted data, silent policy", dict(sensitivity="high",
        task_needs_data=True, controls_stated=False, controls_adequate=False,
        authorizer_named=False, approved_alternative_known=False)),
]

for name, args in scenarios:
    print(f"{name:45s} -> {decide(**args)}")

Expected output:

complaint rewrite                             -> minimize
contract extraction, approved endpoint        -> submit
contract extraction, unknown retention        -> escalate
restricted data, silent policy                -> escalate

Read the third line carefully. The task needs the data, the controls are unknown, and no approved alternative is known — so the function escalates. Change approved_alternative_known to True for that scenario and it returns approved alternative instead. That single flip is the boundary the reflection flagged: the alternative branch is only reachable when a suitable tool is actually known. If you are unsure whether the tool is authorized, set the flag to False and escalate.

Now break it on purpose. Set task_needs_data=True for the complaint rewrite and watch it stop minimizing. The function is not making a policy judgment — it is encoding the order of the questions. If you feed it the wrong necessity answer, it will confidently produce the wrong outcome. That is the same failure mode you have in your head when you skip Question 2.

Warning: This classifier is a teaching scaffold, not a policy engine. It cannot verify that a control is real, that a tool is approved, or that a data class is regulated. It only shows how the four questions compose. Real authorization still comes from a named person or document.

Score Your Own Answers

Practice only helps if it corrects you. For each scenario above, your answer is only as strong as the evidence you can attach to it.

A strong answer names four things: the sensitive element, whether the task needs it, the specific control you relied on or its absence, and the authorizing party.

A weak answer leans on "it's probably fine," on the tool's reputation, or on the fact that a colleague did it last week. None of those are evidence. If you cannot name the control you relied on, you guessed — and the honest move is to redo the scenario.

Where This Procedure Breaks Down

I trust this triage for direct, deliberate submissions. I do not trust it to cover everything, and you should not either.

It assumes the stated controls are accurate and current. Policies change. Vendor terms change. A control you verified six months ago may not hold today.

It does not cover indirect exposure. Data that arrives through retrieved documents, tool outputs, or agent context never passes through your paste box, so the four questions never get asked. That is a different problem with different controls.

It does not replace legal or compliance review for regulated data classes. If the data is regulated, the triage tells you to escalate — it does not tell you the answer.

It cannot detect re-identification risk in data that looks de-identified. A record with the name removed can still point at one person.

When any of these apply, the correct move is escalation, not a more confident guess.

Make It a Habit

Run the four questions on the next three data-bearing tasks you actually face. Write down the outcome and the evidence you used. Keep a short log of which controls you verified and when, so you are not re-litigating the same decision every week.

If you find yourself escalating the same unknown repeatedly, that is a signal the organization needs a stated policy — not that you need better instincts.

Here is the decision rule to carry out of this article: if you cannot name the sensitive element, the task necessity, the stated control for the data you would actually submit, and the authorizing party, the answer is escalate. That is a competent answer. It is the answer that keeps the work moving without pretending you know something you do not.

Once you have decided to proceed, the next skill is doing the minimization well — removing what the task does not need while keeping what makes the output useful. That is where the neighboring practice on minimizing and redacting data picks up.