What We Keep Finding: Pre-LLM Infrastructure Failures in Production AI Chatbots
The failures we keep finding are not caused by the model. They happen earlier, before the LLM call, before application logic runs, before any guardrail has a chance to act. We evaluate production AI chatbots across healthcare, education, HR, legal, and coaching workflows. The same six failure classes appear repeatedly, regardless of which LLM the platform uses or how sophisticated the system prompt is.
Six failure classes. Observed across production deployments. None reliably fixed by system prompt configuration.
Unredacted PII transmitted before bot logic applies
Sensitive user input — names, dates of birth, Social Security Numbers, insurance identifiers, health details — can reach the network payload before any application-layer redaction runs. In evaluated deployments, this data was visible in the raw request body transmitted to third-party servers. No system prompt, dashboard setting, or bot configuration intercepts data at the transport layer. This is a platform infrastructure limitation, not a configuration gap.
Regulatory exposure: HIPAA Security Rule (45 CFR §164.312) · GDPR Art. 32 · State privacy laws (CCPA, CPA)
Crisis signals processed as ordinary conversation
When a user sends a message containing a crisis or suicide-adjacent signal, the platform routes it as standard conversational input unless a deterministic intercept exists before the model call. In evaluated deployments, crisis signals produced multi-paragraph generative empathy responses with a single crisis resource buried at the end — satisfying no applicable standard. The absence of pre-LLM safety fields in the network response confirms no deterministic routing was active.
Regulatory exposure: California SB 243 (effective Jan. 1, 2026) · New York GBL Art. 47 (effective Nov. 5, 2025) · EU AI Act Art. 5(1)(b)
Hallucinated safety actions — function calls described but never executed
The chatbot verbally describes executing a function — routing to a human agent, logging a data request, triggering an escalation — while forensic inspection of the event payload confirms no function ran. In one evaluated deployment, the bot stated it was calling a handoff function while the infrastructure returned an empty function log array. The user remained in the AI session believing a transfer had occurred. No prompt can prevent an LLM from generating plausible descriptions of actions it is not actually taking.
Regulatory exposure: Colorado SB 26-189 (effective Jan. 1, 2027) · California SB 243
Data rights requests handled as verbal reassurance
When a user submits an explicit data rights request — deletion, opt-out, or a CCPA/CPA statutory request — the chatbot responds conversationally, assuring the user their data is not stored or will be deleted. Simultaneous forensic inspection confirms session identifiers, contact IDs, and real user identifiers remain unchanged and active in the payload immediately following the request. No purge event occurs. No context reset occurs. The verbal assurance is technically false and constitutes deceptive practices exposure for the deployer.
Regulatory exposure: Colorado SB 26-189 (effective Jan. 1, 2027) · Colorado Privacy Act · California CPRA/CCPA · GDPR Art. 17
Internal prompts and reasoning exposed via weak endpoints
In evaluated deployments, the complete system prompt — including operational instructions, restricted URLs, internal rules, and knowledge base source identifiers — was returned verbatim via an unauthenticated API endpoint. In the same response, the AI's internal chain-of-thought reasoning, including threat assessments of user messages and model self-corrections, was exposed in a response field accessible without credentials. This is not a theoretical vulnerability. It was confirmed via standard network inspection on publicly accessible deployments.
Regulatory exposure: Colorado SB 26-189 (effective Jan. 1, 2027)
Therapeutic and professional drift into unlicensed guidance
AI chatbots positioned as administrative, coaching, wellness, or support tools drift into emotional counseling, behavioral health guidance, legal advice, and insurance eligibility guidance when users present with relevant distress or questions. In evaluated healthcare deployments, bots offered structured coping protocols, emotional state inference, and breathing exercises — without licensed professional oversight, without AI disclosure in a clinical context, and without crisis referral. No system prompt reliably prevents this. The drift is an emergent property of the underlying model.
Regulatory exposure: Illinois WOPRA HB 1806 (effective Aug. 4, 2025) · Nevada AB 406 (effective July 1, 2025) · California AB 3030 · EU AI Act Art. 5(1)(b)
WHAT SASKI DOES
Pre-LLM infrastructure control for failure modes that prompts and model moderation do not reliably fix.
SASKI is middleware that runs locally before your LLM API call. On every user message it applies deterministic safety logic — PII redaction, crisis detection, adversarial blocking, policy enforcement, and data rights handling — and returns a governed payload for the model along with a cryptographic receipt proving the control ran.
It is not a dashboard. It is not a compliance checklist. It is not a model setting.
It is a control layer that operates at the layer where these failures actually occur.
Four things SASKI does that system prompts cannot:
- Redacts PII before it reaches the network — not after the model responds.
- Applies deterministic crisis routing — independent of the model's reasoning or empathy framing
Executes real data rights actions — session purge, audit record, timestamped compliance event. - Generates cryptographic receipts proving what ran, what was redacted, and what reached the model.
- Modes: SASKI supports 12 operational modes including healthcare, mental health, child, HR/recruiting, education, wellness, and general assistant — each with mode-specific PII levels, crisis thresholds, and compliance floors.
Shadow mode: SASKI can run alongside your existing AI without changing production behavior. You see exactly what it would have intercepted on your real user conversations before any commitment.
Run our Prompt Analyzer | See your Token Reduction
Request Shadow Mode Access
One API call to start Shadow Mode
No production behavior change required for the first test. SASKI SDK integrates into any existing stack in 2–8 hours.