Is Lakera still independent after the Check Point acquisition?

Lakera was acquired by Check Point in 2025. The product line continues under the Check Point AI security umbrella. Buyers evaluating the product should ask Check Point directly about roadmap commitments under the new structure, including SDK versus proxy investment, multi-cloud coverage plans, and integration with the Check Point CloudGuard product family.

Can Lakera and an HTTP-proxy gateway run together?

The two placements are additive. The Lakera SDK can run inside the application as a content classifier that the developer calls before the LLM call. The HTTP-proxy gateway sits at the request boundary and authenticates the caller against the corporate IdP. The proxy can carry the canonical record series for the audit while the SDK supplies additional adversarial-pattern checks the proxy's classifier may not cover.

How do cloud-native guardrails compare on cost?

Cloud-native guardrails (Bedrock Guardrails, Azure AI Content Safety) typically price as a per-token or per-request charge inside the cloud bill. SDK and proxy products price per seat, per request, or per protected endpoint depending on the vendor. The cost comparison only tracks when the buyer fixes the coverage shape first: a single-cloud deployment can compare cloud guardrail cost against proxy cost on the same traffic; a multi-cloud deployment is comparing different coverage shapes.

What does an EU AI Act Article 12 record require that a content classifier alone does not produce?

Article 12 requires automatic recording of events sufficient to ensure traceability of the AI system. Article 19 specifies the record carry identification of natural persons involved. A content classifier produces the classification decision and the prompt text. It does not produce the natural-person identity unless an identity layer is in front of it. The HTTP-proxy placement with IdP integration captures the identity at the moment of the request, which is the field the classifier alone is not positioned to capture.

Does the proxy add latency that affects the user experience?

End-to-end inspection overhead measures under 50 ms in DeepInspect's internal testing. LLM inference itself takes 500 ms to 5 seconds depending on the model and the request size. The inspection overhead sits inside the variance of the inference round-trip, so user-perceived latency does not move when the inspection layer goes inline.

Lakera Alternatives: A Buyer-Side Comparison of Enforcement Architectures for Enterprise AI Traffic

Lakera (now part of Check Point) ships a content classification product that scores prompts and responses against a library of adversarial patterns, including prompt injection variants, PII categories, and policy violations defined per organization. The product integrates as an SDK in application code or as an HTTP-proxy variant. Most enterprise buyers I talk to who shortlist Lakera are also shortlisting two adjacent architectures: dedicated AI gateways that enforce identity-based policy on the HTTP request boundary, and model-side guardrails offered by cloud providers (Bedrock Guardrails, Azure AI Content Safety). The shortlist is shaped less by feature parity and more by where each option places enforcement relative to the user identity and the audit record.

I want to walk through the architectural axes I see buyers care about, what each axis implies, and how the alternatives sit against Lakera on those axes.

TL;DR

Lakera is a content classifier with strong adversarial-pattern coverage. Buyers compare it against identity-aware enforcement gateways (DeepInspect, AI gateways with policy modules) and cloud-native model guardrails (Bedrock Guardrails, Azure AI Content Safety). The right choice tracks whether the program needs identity-bound per-request records for regulatory audit, multi-model coverage across vendors, or model-side default-deny on a single cloud.

Axis one: enforcement placement

Enforcement placement is the single most consequential axis. The classifier can sit inside the application code (an SDK that the developer calls before the LLM call), at an HTTP proxy in front of the LLM (a gateway the application points its base URL at), or inside the inference layer of the model itself (a provider-managed module the cloud runs on the model's behalf).

Lakera's SDK placement keeps the classifier inside the application, which means every application team integrates separately and the inspection coverage tracks the SDK rollout. Lakera's proxy variant moves the placement to the HTTP boundary, which centralizes coverage but requires routing decisions for every LLM endpoint the organization calls. AI gateway alternatives ship the proxy placement as the primary deployment shape, so the coverage is uniform across services from day one. Cloud-native guardrails sit inside the inference layer of one provider, which gives strong placement on AWS or Azure traffic and zero placement on traffic to other providers.

Axis two: identity binding

Identity binding is the question that EU AI Act Article 19 makes consequential: the audit record must identify the natural person involved. An SDK that runs inside an application can see the session identity the application authenticated against. An HTTP proxy that terminates TLS at the inspection layer can authenticate the caller against the corporate identity provider directly at the boundary, which gives identity binding to every request including ones the application would have sent under a service credential. A cloud-native guardrail running inside the model inference layer sees the API caller (a service identity) but not the natural person sitting behind the application session.

For buyers building toward an Article 19 record series, the identity binding question reduces to which placement can authenticate against the corporate IdP at the moment of the request. The HTTP proxy with IdP integration is the placement that supports that field on every record. Lakera's SDK supports it when the developer wires it through. The cloud-native guardrails do not support it without a separate identity layer in front.

Axis three: audit record shape

The audit record shape question is what an auditor would actually receive when they sample a high-risk decision. The fields the EU AI Act Article 19 and Article 12 expect include timestamps, input data (the prompt), identification of natural persons involved, and policy state at the moment of decision. HIPAA Security Rule 45 CFR 164.312(b) expects audit controls on systems that process PHI with similar field expectations.

Lakera's records capture the classification decision, the prompt text, and the rule that fired. An HTTP-proxy enforcement gateway with IdP integration captures identity, classification, policy version, decision, timestamp, and an integrity signature in the same record. Cloud-native guardrails capture the model-side decision and the prompt in the provider's logging surface, which the auditor receives through the provider's compliance reports, not as a per-decision record the enterprise controls.

Axis four: multi-model coverage

Multi-model coverage is the question of whether the enforcement layer covers traffic to OpenAI, Anthropic, Google, AWS Bedrock, Azure OpenAI, self-hosted LLMs, and internal RAG pipelines on the same policy surface. Lakera's SDK and proxy are model-agnostic. AI gateway alternatives are typically model-agnostic by design. Cloud-native guardrails cover the provider's own model surface and do not cover traffic to other providers from the same deployment.

A single-cloud enterprise can pick a cloud-native guardrail and accept the coverage shape. A multi-cloud enterprise running OpenAI, Anthropic, and Bedrock side by side cannot, because the policy state would diverge across the three guardrail products with no shared record series.

Axis five: how the buying decision usually lands

The buyers I talk to who pick Lakera usually do so because the classifier coverage on adversarial patterns matches a specific threat model they already mapped, and the SDK integration fits the team that owns the application stack. The buyers who pick an HTTP-proxy enforcement gateway usually do so because the program is building toward an EU AI Act Article 12 record series across multiple application teams and multiple LLM providers, and the centralized placement keeps the record consistent. The buyers who pick a cloud-native guardrail usually do so because the deployment is single-cloud and the cloud provider already holds the compliance reporting relationship.

The three options are not strictly competitive. A real program often runs a Lakera classifier inside the application, an HTTP-proxy enforcement gateway at the boundary, and a cloud-native guardrail on the provider-side surface, with the proxy as the canonical record series the auditor samples against.

DeepInspect

DeepInspect is the HTTP-proxy enforcement gateway shape of this comparison. It sits inline between authenticated users or agents and any LLM, terminates TLS at the proxy, authenticates against the corporate IdP, runs deterministic classification against the prompt content, evaluates policy against identity and classification, and commits a per-decision audit record before the response returns to the application. The records carry the fields EU AI Act Article 12 and Article 19 expect on the series HIPAA Security Rule references.

For organizations evaluating Lakera against alternatives, the framing I find useful is to map the program's audit obligations against the placement options. If the program needs identity-bound per-request records across multiple providers, the proxy placement is the one that produces them.

If you are facing the August deadline, let's talk.