Cloud & on-prem

Local routing of a request that carries patient data

A private hospital group wants an assistant that finds its internal procedures from ward workstations. Some requests quote patient data, and those must never leave the hospital network.

Invented caseThis case is not an engagement. It is invented end to end, and the code below is the real code that would run it.

1. Human·Request from the ward

   Patient MRN 4417832, admitted to cardiology yesterday, is on an anticoagulant. What is the internal procedure before a GI endoscopy?

2. The agent·Classifying the request

   I read the request before choosing a model. MRN followed by seven digits triggers the patient_identifier rule. Destination: local, no network egress. Without that match, generic_procedure would have sent it out: it is the only rule that allows egress, and it demands the absence of any patient pattern. A request that no rule classifies stays local by default.

   A forgotten pattern is never the reason a request goes out.

3. Tool call·Calling the local model

   {
     "tool": "procedures_assistant.answer",
     "rule_applied": "patient_identifier",
     "trigger_match": "MRN 4417832",
     "destination": "local",
     "host": "gpu-01.intra.hospital",
     "network_egress": false,
     "request": {
       "text": "Patient MRN 4417832, admitted to cardiology yesterday, is on an anticoagulant. What is the internal procedure before a GI endoscopy?",
       "requesting_unit": "cardiology",
       "role": "nurse"
     },
     "corpus": [
       "care_procedures",
       "endoscopy_protocols"
     ],
     "similarity_threshold": 0.62
   }

4. Tool response·Passages found on site

   {
     "status": "ok",
     "compute": {
       "location": "hospital server room",
       "host": "gpu-01.intra.hospital",
       "network_egress": false
     },
     "passages": [
       {
         "document": "PROC-END-014",
         "version": "4.2",
         "section": "Stopping anticoagulants",
         "similarity": 0.81
       },
       {
         "document": "PROC-END-014",
         "version": "4.2",
         "section": "Delay before the procedure",
         "similarity": 0.74
       }
     ],
     "missing_sections": [
       "Heparin bridging"
     ],
     "below_threshold": [
       {
         "document": "PROC-CARD-007",
         "section": "Renal function",
         "similarity": 0.41
       }
     ],
     "document_to_revalidate": {
       "reference": "PROC-END-014",
       "revision_overdue": true
     }
   }

   The missing_sections field exists so the answer can say what it does not find.

5. Tool call·Writing the trace

   {
     "tool": "audit.record",
     "event": "assistant_request",
     "logged": {
       "timestamp": "2026-09-03T08:41:12+02:00",
       "rule_applied": "patient_identifier",
       "destination": "local",
       "network_egress": false,
       "requesting_unit": "cardiology",
       "request_fingerprint": "sha256:9c2d41ab7e0f5b83",
       "documents_read": [
         "PROC-END-014"
       ]
     },
     "never_logged": {
       "fields": [
         "request_text",
         "patient_identifier",
         "date_of_birth",
         "generated_answer"
       ],
       "reason": "the log proves the routing, it does not replay the patient record"
     },
     "retention_days": 365
   }

   The trace proves a request did not leave. It cannot rebuild who the patient was.

6. Answer·Answer returned to the ward

   Procedure PROC-END-014, version 4.2, requires stopping the anticoagulant before the procedure, with a delay that depends on the drug. Heparin bridging is not covered by this document: I will not invent it, so call the cardiologist on duty. Another document has a section on renal function, but it falls below the similarity threshold, so I leave it out. The compute ran on the hospital server and the request never left the network. The document is past its revision date, so have the version confirmed before the procedure.

version: 3
policy: internal-procedures-assistant

destinations:
  local:
    engine: on-site-model
    host: gpu-01.intra.hospital
    network_egress: false
  external:
    engine: hosted-model
    host: api.third-party-provider
    network_egress: true

# local rules run first so a patient pattern always wins
evaluation_order: [patient_identifier, identifying_detail, generic_procedure]

rules:
  patient_identifier:
    patterns:
      - '\bMRN\s?\d{6,9}\b'
      - '\bADM\s?\d{6,10}\b'
      - '\b[12]\d{2}(?:0[1-9]|1[0-2])\d{8}\b'
    destination: local
    log_text: false
  identifying_detail:
    patterns:
      - '\broom\s?\d{1,3}\b'
      - '\bborn on \d{2}/\d{2}/\d{4}\b'
    destination: local
    log_text: false
  generic_procedure:
    patterns:
      - '(?i)\b(procedure|protocol|checklist|standard of care)\b'
    destination: external
    log_text: true
    requires_absence_of: [patient_identifier, identifying_detail]

# the guard: an unclassified request is handled as if it held a patient
default:
  destination: local
  log_text: false

audit:
  logged_fields: [timestamp, rule_applied, destination, network_egress, requesting_unit, request_fingerprint, documents_read]
  forbidden_fields: [request_text, patient_identifier, date_of_birth, generated_answer]
  retention_days: 365

# the service refuses to start rather than run on a permissive policy
startup_checks:
  refuse_if_default_external: true
  refuse_if_rule_without_destination: true
  refuse_if_pattern_invalid: true

Patient data leaving the network is almost never a model problem: it is a policy file whose default rule lets the request out.