Does LLM Guard satisfy EU AI Act Article 12 by itself?

Article 12 requires automatic event logging over the system lifetime at a level appropriate to the intended purpose. LLM Guard can produce scanner verdicts, and the application team decides how to retain them. A high-risk-system programme needs to assess those records with the system documentation, operator roles, and the requirements that apply to the specific deployment. A proxy record can add independent evidence for the routed request, though it does not replace the rest of that assessment.

Can DeepInspect run LLM Guard's scanners?

The scanner concepts overlap with DeepInspect's classification step. DeepInspect classifies prompt content for PII, PHI, prompt-injection signatures, and policy-defined data classes at the proxy layer. The classification result feeds the policy decision. DeepInspect supports plugging classifier stages into the policy chain when a customer wants to reuse an existing scanner. Most deployments find the DeepInspect-native classification covers the same ground LLM Guard scanners do, without the in-process integration overhead.

What if our application teams already use LLM Guard?

Keep LLM Guard at the call site if its scanners fit the application. Place the DeepInspect proxy between the application and the LLM provider. The scanner stack runs before the prompt leaves the process, then the proxy runs identity and policy checks on the outbound HTTP call. The paths serve separate purposes and can coexist.

How does this comparison hold for vendor SaaS AI usage?

LLM Guard requires application code changes, so it cannot scan a vendor SaaS application's hidden model call. A customer should verify each vendor's logging and evidence commitments directly. DeepInspect only observes SaaS-to-LLM traffic that routes through a configured HTTP proxy; an egress design must be validated for every flow. For related design work, see AI gateway architecture, AI audit-log immutability, and EU AI Act Article 12 logging.

DeepInspect vs LLM Guard: Two Different Layers of the AI Stack

Protect AI's LLM Guard is an open-source Python toolkit that scans LLM inputs and outputs for prompt injection patterns, PII, and policy violations. The scan runs inside the application process and returns a verdict the application code acts on. DeepInspect operates at a different layer: an HTTP proxy that intercepts routed AI traffic before it reaches the model and records an identity-bound policy decision.

I want to walk through how the two tools differ architecturally, what each one covers, and how the buying decision changes when EU AI Act Article 12 or NIST AI RMF identity-and-authorization framing enters the requirement set.

TL;DR

LLM Guard adds content scanners inside a Python application. DeepInspect evaluates identity-aware policy on HTTP requests that reach its proxy and stores the routed decision separately. They can operate together, but a regulated AI system also needs evidence for human review and every path outside the proxy.

Quick comparison

LLM Guard is an in-process scanner that returns verdicts to the application. DeepInspect is an external enforcement layer that intercepts AI traffic at the HTTP boundary, enforces identity-aware policy, and writes per-decision audit records the application cannot reach.

LLM Guard: where it sits

LLM Guard is a Python library distributed under the MIT license by Protect AI. The library exposes a collection of "scanners" for input and output side of an LLM call. Input scanners include detectors for prompt injection, PII, prompt-template tampering, and token limits. Output scanners include toxicity, factual consistency, and refusal-pattern checks.

The execution model is a function call inside the application. A developer imports the library, instantiates the scanners, and passes the prompt through them before the LLM call. The scanners return a sanitized prompt or a hard refusal. After the LLM responds, the output scanners run a second pass.

What LLM Guard handles well

Single-application prompt sanitization. PII detection at the prompt level via the same scanner libraries the broader Protect AI suite uses. Prompt-injection regex matches against the Lakera, Rebuff, and Garak adversarial datasets. Lightweight integration when the application is greenfield and the team owns the LLM call site.

Where LLM Guard ends

The scanner sees the prompt text. The scanner does not see the identity of the user behind the prompt. The verdict is logged inside the application. The application can ignore the verdict in code branches the security team never reviews. If the application crashes mid-call, the verdict is lost. The same application that handles the LLM request also writes the audit log, which fails the self-attestation test the EU AI Act applies.

Where DeepInspect sits

DeepInspect intercepts the HTTP request as it leaves the application en route to the LLM provider. The proxy reads identity headers the application supplies, evaluates policy against per-route and per-role rules, classifies the prompt content, decides permit or redact or deny, and commits a per-decision audit record to a tamper-evident log before the model response returns. The record contains identity, role, policy version, classification, decision outcome, and a cryptographic signature.

The execution model is out-of-process. The application makes its HTTP call to the DeepInspect endpoint instead of directly to the LLM provider. The proxy is the policy decision point. The audit record lives independent of the application.

What DeepInspect handles

DeepInspect provides identity-bound enforcement on LLM endpoints that route through its HTTP proxy. It records policy decisions before the application receives a response. The records can support an Article 12 evidence design, yet the full legal record also depends on the high-risk system's documentation and non-routed events. NIST's AI Risk Management Framework provides a useful voluntary structure for mapping those controls. Enforcement adds under 50 milliseconds in internal testing.

Feature comparison

Execution model: LLM Guard runs in the Python application process. DeepInspect runs as an out-of-process HTTP proxy.
Policy scope: LLM Guard depends on an integration at each call site. DeepInspect applies per-route and per-role policy to traffic that traverses its proxy.
Identity context: LLM Guard receives the context the application passes to it. DeepInspect requires identity context on each routed request.
Audit evidence: LLM Guard's verdict can be written by the application. DeepInspect commits a separate record for each routed policy decision.
Prompt and PII checks: Both can classify prompt content. LLM Guard supplies scanner libraries; DeepInspect uses classification as input to a policy decision.
Deployment and licensing: LLM Guard is MIT-licensed. DeepInspect is a commercial deployment discussed through sales.

Pick LLM Guard if

You are building a single LLM application and you control the call site. You want prompt-injection regex and PII scanners that ship with sensible defaults. You are comfortable maintaining the scanner stack in your application's deployment pipeline. The regulatory exposure is light and identity-aware logging is handled by a separate audit system the application code writes into. You want an MIT-licensed toolkit you can read and modify.

Pick DeepInspect if

Choose DeepInspect when a regulated deployment needs identity-aware policy decisions on HTTP traffic to LLMs. A shared proxy can make those decisions consistent across routed application endpoints. The programme still needs separate evidence for local processing, human review, and vendor systems that do not traverse the proxy. Annex III high-risk-system requirements apply from 2 December 2027 under Regulation (EU) 2026/1744.

Pricing approach

LLM Guard is free under the MIT license. The operational cost is engineering integration time and infrastructure for the application that hosts the scanners. Updates require redeploying the application. DeepInspect is commercial and priced per-deployment based on traffic volume. Pricing is communicated through sales conversations.

DeepInspect

DeepInspect was built for regulated environments where a routed policy record matters alongside prompt classification. LLM Guard inspects content inside the application. DeepInspect enforces identity-aware policy on HTTP traffic to the LLM.

Some deployments run both tools. LLM Guard can sanitize prompts inside a chatbot before they leave the process. The proxy then evaluates identity and policy on the outbound HTTP call and preserves the routed decision independently. This design does not inspect local tool execution or downstream actions outside that HTTP path.

For a complete decision record, map the system's application logs, human-review evidence, and routed model-request record before the Annex III date arrives. Book a demo today.