Lakera Guard Pricing: Free Allowance and Enterprise Scope

Lakera Guard pricing starts with a Community plan at $0 per month and 10,000 requests. Enterprise uses a custom quote and flexible request capacity. The public matrix also changes hosting and support, plus identity controls and SIEM integration. Version pinning and data residency also change. A useful budget therefore counts screened requests and prompt size, then assigns separate owners to deployment and evidence retention. Model inference and any independent authorization layer need separate owners too.

TL;DR

• The Community plan costs $0 per month and includes 10,000 requests each month.
• Community supports prompts up to 8,000 tokens and runs as SaaS with community support.
• Enterprise uses flexible request capacity, configurable prompt size, and SaaS or self-hosted deployment.
• SSO and role-based access appear in the Enterprise column. SIEM integration appears there too.
• The public page provides no numeric Enterprise rate, so the signed quote must define the billing unit and included capacity. It must also define overages, support, and renewal terms.

Lakera Guard pricing has two public plan shapes

The current Lakera Guard pricing page lists Community and Enterprise. Community is $0 per month and includes 10,000 requests each month. Its maximum prompt size is 8,000 tokens. The plan runs as SaaS and carries community support. API access and dashboards appear in both columns. Reports, encryption in transit and at rest, and the page's stated SOC 2 and GDPR status also appear in both columns.

Enterprise replaces the fixed allowance with flexible request capacity and marks prompt size as configurable. The page directs buyers to a sales conversation instead of publishing a dollar rate. That makes the Community tier directly budgetable and the Enterprise tier quote-led.

I would reject any spreadsheet that extends the Community allowance into an assumed Enterprise unit price. Ten thousand requests are an entitlement, not a discount curve.

Enterprise changes deployment and control entitlements

The Enterprise column names SaaS or self-hosted hosting and enterprise-level support. It also includes SSO and role-based access control. SIEM integration appears there too. Community omits those controls. Data residency is listed as EU for Community and EU or US for Enterprise.

Version pinning has a narrower boundary. The matrix marks it as available only for self-hosted Enterprise deployments. A buyer that needs a fixed detector version for regression testing should capture the hosting choice and pinning entitlement in the order form. The quote should also state who operates upgrades and how security fixes affect a pinned release. It should state how long a version remains supported.

Put the matrix on one screen and the proposed architecture on another. Mark each entitlement beside the component that uses it. The AI security vendor evaluation criteria provide a broader route, identity, action, and evidence checklist for this review.

Screened requests need a workload model

The pricing page uses requests as the visible allowance, while prompt size is a separate plan limit. Forecast input and output screening according to the actual integration. A workflow that screens a prompt and then screens the model response may create two evaluation events around one model call. The signed quote should define what Lakera counts as a billable request.

Measure production-shaped prompts instead of using an average from a small test. Record daily volume and peak concurrency. Record input size, response size, retries, timeouts, and duplicate screening. Include development and staging, plus regression tests and red-team runs. Those environments can consume meaningful capacity even though they serve no end users.

The Check Point AI Guardrails documentation describes screening for prompt attacks and content moderation. It also covers data leakage, malicious links, and agent behavior. It describes managed and custom guardrails as well. Each enabled policy can change testing and review work, even when the commercial meter remains request-based.

The current product identity belongs in the quote

The pricing portal still uses the Lakera Guard Platform name. The current documentation uses Check Point AI Guardrails and describes a wider AI Security platform. Procurement should preserve both names in the review so a legacy search term and dashboard label resolve to the same contracted service as the current order form.

Ask the vendor to identify the legal seller and service name in writing. The vendor should also identify the plan, deployment model, support package, and documentation version. The quote should state whether the Community and Enterprise matrix applies to the current Check Point product and which wider platform capabilities are included. Avoid carrying an entitlement across names simply because both pages describe guardrails.

The DeepInspect and Lakera comparison covers the architectural distinction between content screening and identity-bound request policy. Pricing should follow the selected job rather than a broad AI security label.

Quote normalization needs six separate lines

Start with the Lakera license or service charge and its included request capacity. Add overage treatment and any minimum commitment. Then separate self-hosted infrastructure and support from SIEM storage and engineering work. Keep model-provider inference separate as well. A guardrail request and an LLM request are related operating events with different cost owners.

The quote should answer six questions:

• Which event counts as one screened request?
• How are prompts above the configured size handled and billed?
• Which guardrails and custom policies are included?
• What support response and availability commitment apply, and what service credits apply?
• Which logs can be exported, and what retention is included?
• What happens to pricing at renewal or after capacity exceeds the commitment?

Run a controlled month with tagged traffic. Reconcile Lakera's request count against application events and provider calls. The best AI gateway guide explains why route evidence and model-provider spend should remain distinct from a security service's own meter.

DeepInspect

DeepInspect evaluates authenticated HTTP model requests that an application deliberately routes through its proxy. It binds application-supplied identity and role to a versioned policy. It evaluates the data class and destination, then records the decision outside the calling application's write path.

Check Point AI Guardrails can screen routed content for the configured threat and safety categories. DeepInspect owns the separate authorization question for a specific caller and role, applied to a data class and model route. Price each layer against its own traffic and evidence requirements. Price its support requirements separately. Book a technical deep dive at deepinspect.ai.