Can I use DeepInspect with AWS Bedrock?

Yes. DeepInspect sits on the HTTP path between the calling identity and any LLM endpoint, including Bedrock. The proxy can route to Bedrock for AWS-hosted models and to other providers for non-AWS models, while applying consistent identity-bound policy and producing a unified audit record across the footprint.

Can Bedrock Guardrails be used with non-AWS models?

No. Bedrock Guardrails are integrated into the Bedrock service and apply only to models hosted on Bedrock. For non-AWS LLM endpoints, the equivalent control is a separate inspection layer or the provider-specific feature set (OpenAI's moderation API, Anthropic's safety features, Azure OpenAI's content filters).

How is the audit record different between the two?

Bedrock Guardrails produce records in CloudTrail and Bedrock-specific logs, written by AWS as the cloud provider. The records cover the guardrail decision and the model invocation within Bedrock. DeepInspect produces a per-decision audit record written by the inspection layer, independent of the LLM provider, with identity, role, classification, policy state, decision outcome, and cryptographic signature. The two records differ in independence, content, and integrity guarantees.

Which one satisfies the EU AI Act Article 12 requirement?

The Article 12 record-keeping mandate presumes a per-decision audit record committed independently of the application. DeepInspect's external enforcement record meets this expectation by architecture. Bedrock Guardrails' record sits inside the AWS-managed Bedrock environment; the deployer using Bedrock as the primary control should evaluate whether the AWS-managed record satisfies the independent-record analysis in the specific deployment context.

Can the two be used together?

Yes. The two operate at different layers. DeepInspect at the AI request boundary can apply identity-bound policy and commit the per-decision record. Bedrock Guardrails at the inference boundary can apply content safety filters at the model layer. The composition gives the deployer both architectural depth at the AI request boundary and the content-safety features AWS provides for Bedrock-hosted models. Book a technical deep dive at deepinspect.ai.

DeepInspect vs Bedrock Guardrails: How an Inline Enforcement Proxy and an Inference-Side Filter Differ

DeepInspect and AWS Bedrock Guardrails both apply policy to LLM traffic but operate at different layers of the architecture. DeepInspect is a vendor-neutral policy enforcement proxy that sits inline on the HTTP path between calling identities and any LLM endpoint, including Bedrock, OpenAI, Anthropic, Azure OpenAI, and on-premise models. Bedrock Guardrails are inference-side content filters integrated into the AWS Bedrock service. The two share vocabulary around content filtering, PII detection, and topic restriction. They differ in where the enforcement happens, which LLMs they cover, and who writes the audit record.

I want to walk through what each one is, where each sits in the architecture, what the audit record each produces contains, and the buyer-fit framing for picking one or both.

TL;DR

DeepInspect is an external policy-enforcement proxy that produces a per-decision audit record bound to enterprise identity for any LLM endpoint. Bedrock Guardrails are inference-side filters integrated into Bedrock that cover the AWS-hosted model surface. Buyers with multi-vendor LLM footprints, EU AI Act high-risk obligations, or independent-record requirements typically need DeepInspect. Buyers with AWS-Bedrock-only deployments and content-safety needs may use Bedrock Guardrails as the primary control or as a complement.

AWS Bedrock Guardrails: what they are and where they sit

Bedrock Guardrails are content filters that AWS exposes as a configurable feature of the Bedrock service. The feature provides denied-topics, content-filter, sensitive-information-filter, word-filter, and contextual-grounding capabilities. The filters operate at the inference layer: the prompt and the response pass through the guardrail before reaching the application. AWS manages the guardrail infrastructure as part of the Bedrock managed service.

Bedrock Guardrails apply to models hosted on Bedrock: Anthropic Claude on Bedrock, Meta Llama on Bedrock, Mistral on Bedrock, Amazon Titan, and the other models AWS surfaces through the Bedrock API. The guardrails do not apply to models hosted outside Bedrock: OpenAI's API, Anthropic's direct API, Google's Gemini API, Azure OpenAI, or self-hosted models on EKS or EC2.

The audit record AWS produces sits in CloudTrail and the Bedrock-specific logs. The record covers the API call, the guardrail decision, and the model invocation. The record is generated by AWS, the cloud provider whose service is the subject of the audit. The deployer using Bedrock Guardrails as the primary control writes to a log produced by the system under audit, which has implications for independent-record analysis under EU AI Act and DORA reviews.

DeepInspect: what it is and where it sits

DeepInspect is a stateless policy-enforcement proxy that sits inline on the HTTP path between authenticated users or agents and any LLM endpoint. The proxy terminates the AI provider TLS, reads the request body, attaches the enterprise IdP identity through propagation, evaluates per-route, per-role, identity-bound policy against the prompt classification, applies a pass, redact, or block decision, commits the per-decision audit record, and forwards the request to the model.

DeepInspect operates above the LLM provider boundary, which means it covers all LLM endpoints the deployer routes through it: Bedrock, OpenAI, Anthropic, Azure OpenAI, on-premise models, and any other HTTP-based LLM. The per-decision record contains identity, role, classification, model and version, policy state, decision outcome, and cryptographic signature, committed by DeepInspect independent of the application and independent of the LLM provider.

Feature comparison

| Capability | DeepInspect | Bedrock Guardrails | |---|---|---| | Vendor coverage | Any HTTP-based LLM | AWS Bedrock-hosted models only | | Inline policy enforcement at the AI request boundary | Core | Available at the Bedrock boundary | | Per-decision audit record bound to enterprise identity | Core | Bedrock and CloudTrail logs | | Independence from the LLM provider | Architectural | AWS-managed | | Identity propagation from enterprise IdP | Core | Requires application-side configuration | | Prompt-level classification at request time | Core | Available | | PII detection and redaction | Core | Available | | Topic and denied-words filtering | Available | Core | | Fail-closed default under uncertainty | Core | Configurable | | Multi-vendor model routing | Available | AWS-only | | Cryptographically signed audit record | Core | CloudTrail integrity protection | | Cross-account governance | Available | Available through AWS Organizations |

Pick Bedrock Guardrails if

The buying decision favors Bedrock Guardrails when the AI deployment is AWS-only and the primary need is content safety at the inference boundary.

The deployer's full LLM footprint runs on Bedrock. There is no OpenAI usage, no direct Anthropic API usage, no Azure OpenAI, and no self-hosted models outside AWS. The deployer is comfortable with AWS as both the cloud provider and the audit-record writer.

The primary procurement driver is content safety: denied topics, harmful content filters, and PII redaction at the inference layer. The deployer accepts the AWS-managed audit posture as sufficient for the deployment's regulatory profile.

The deployer wants the integration to be a configuration of an existing AWS service rather than a separate inspection layer to deploy and operate.

Pick DeepInspect if

The buying decision favors DeepInspect when the deployment spans multiple LLM providers, when the regulatory profile requires an independent per-decision record, or when the agent and identity model requires per-call enforcement at the request boundary.

The deployer's LLM footprint includes OpenAI, Anthropic direct, Azure OpenAI, or any non-Bedrock endpoint alongside Bedrock. A vendor-neutral inspection layer is necessary to maintain a consistent policy and record across the footprint.

The deployer is preparing for the August 2, 2026 EU AI Act high-risk effective date or the August 6, 2026 Fannie Mae LL-2026-04 effective date, and the binding requirement is the contemporaneous, identity-bound, classification-aware per-decision record committed independently of the LLM provider being audited.

The deployer operates AI agents that call multiple LLMs and multiple tool APIs, and the per-call enforcement and audit are the architectural requirements that the inference-side filter cannot address by construction.

The deployer values architectural independence from the LLM provider as part of the audit posture.

Pricing approach

Bedrock Guardrails pricing follows the AWS Bedrock model: usage-based, billed per request through the Bedrock service, with the guardrail features adding incremental per-request charges layered on top of the model inference cost. The cost is consolidated in the AWS bill.

DeepInspect prices through sales conversations based on AI request volume and deployment topology, with multi-year terms typical for regulated buyers. The cost is separate from any cloud-provider billing. A direct comparison should consider both the Bedrock guardrail per-request charges across the full AI footprint and the DeepInspect platform fee against the same throughput.