Approve the sanitized payload *before* it reaches the external LLM. Every decision logged. For workloads where "mostly anonymized" is not good enough.

When to use HITL

HITL is an add-on for the highest-stakes workflows — typically legal, medical, and regulatory contexts where the cost of an accidental leak is catastrophic. Examples:

• A law firm’s litigation support requires a partner to sign off on every outbound payload during trial prep
• A hospital’s clinical-decision-support agent must have a senior clinician confirm the request for any case-specific LLM query
• A regulator auditing EU fund beneficiaries requires a supervisor’s approval before any anonymized beneficiary data touches a general-purpose LLM

For routine workloads, HITL adds latency and cognitive load without proportional benefit. Use it where the stakes justify it.

How it works

A request hits StellarGate. Instead of forwarding immediately, it enters a queue.

1. StellarGate anonymizes the prompt as usual
2. The request is added to the approval queue for the designated reviewer
3. The reviewer sees the original prompt alongside the anonymized version
4. Reviewer clicks Approve, Modify, or Reject
5. If approved, the payload goes to the LLM; if rejected, the caller gets an error; if modified, the edited payload is sent and logged
6. Response (if any) is de-anonymized as usual and returned to the caller

Trigger rules

HITL can be required unconditionally or based on rules you configure. Rules can fire on any combination of detected entities, amount thresholds, target LLM, requesting user, and probabilistic spot-checks for quality assurance — and they compose, so a rule like “external LLM AND amount > €100K AND junior analyst” is a single expression.

Reviewer experience

Reviewers see an approval queue with:

• Original prompt (with entities highlighted by category)
• Anonymized version (with tokens highlighted)
• Detected mapping (click to verify any detection)
• Metadata — requesting user, timestamp, target LLM, rule that triggered HITL

Three actions:

• Approve — send as-is
• Modify — edit the sanitized prompt, then send. Edits are logged.
• Reject — block the request. Caller receives an error. Rejection reason is captured.

Latency expectations

HITL adds human latency to the request path. For interactive use cases, the caller waits — typically this is fine because users expect a pause for a regulated workflow. For batch workloads, requests queue up.

Options to reduce latency:

• Standing approvals — pre-approve classes of requests for a time window (e.g. next 4 hours)
• Multi-reviewer — any reviewer in a pool can approve, routing to the first available
• Asynchronous mode — caller provides a callback URL, gets the response when approved

Escalation & multi-signature

Configure thresholds that require multiple reviewers:

• Amount > €1M → requires 2 approvers
• Patient file in oncology → requires an oncologist + a compliance officer
• Emergency override → requires a single named executive

Escalation rules can route automatically based on time-of-day, reviewer availability, or severity.

Audit trail

Every HITL decision is logged immutably:

• Who reviewed
• When
• What they saw (original + anonymized)
• What they decided
• Any modifications they made
• Rejection reason if applicable

Exportable for compliance audit, ethics committee review, or court submission. See Audit Log.

SLA dashboards

Track the performance of your review process:

• Average approval time
• Rejection rates
• Modification rates (a high rate suggests your detection rules need tuning)
• Reviewer workload distribution
• Time-of-day patterns

Pricing

€0.05 per approval, or €15 per reviewer per month for unlimited approvals. See API pricing.

Related

• Operating Modes
• What We Detect
• Audit Log