I'm building a workflow where users upload documents through a frontend, and I need to detect PII before sending anything to a generative model. Ideally, uploads containing PII should be rejected and the user should be told what needs to be cleaned up. I'm comparing Amazon Comprehend's PII entity detection with Amazon Bedrock Guardrails, particularly their detection accuracy, confidence scores, JavaScript SDK support, cost, document-size limits, and ability to process files or batches. I'm also considering anonymization or de-identification later. For now, I want to avoid sending the actual document contents to an LLM. One alternative we currently use is sending only column names to a model so it can estimate which columns might contain PII, but we would prefer a dedicated NLP or NER-based solution if Comprehend is a better fit.
4 Answers
I would avoid using a generative model to inspect the actual values if the requirement is that PII must never reach an LLM. A dedicated detector such as Comprehend is safer for that boundary. Sending only column names to a model can help classify likely sensitive fields, but it is only an inference about the schema and cannot reliably detect PII embedded in the values. You may want to combine schema rules, deterministic checks such as email or phone patterns, and Comprehend for entity detection.
For large documents, stored files, or batch processing, Comprehend is generally the more natural choice. You can run the result through application logic and decide whether to reject, redact, anonymize, or continue. Guardrails is more convenient when the content is already being sent through Bedrock and you simply want a synchronous block or filter. Be sure to compare supported document formats, size limits, regional availability, latency, and pricing for your workload.
The main distinction is where the detection happens and how much control you need. Amazon Comprehend is a dedicated NLP service that can return detected entities, entity types, offsets, and confidence scores. That makes it useful when you want to inspect results, apply your own threshold, reject an upload, or redact and store a processed copy. It receives the text for analysis, but it is not a generative LLM call. Bedrock Guardrails is primarily designed to enforce policies around a Bedrock model invocation, such as blocking or masking sensitive content before the model processes it. It is a better fit for runtime protection, but may provide less flexibility for an independent document-validation workflow.
Some teams use a lightweight prompt-based model for redaction because it can be inexpensive and flexible, but that approach still exposes the original content to the model and may miss or incorrectly alter entities. It does not seem appropriate for your current requirement. A managed sensitive-data detection service, followed by explicit thresholds and validation rules in your application, is the safer starting point.
That distinction helps. Our priority is rejecting the upload before any generative model call, so the confidence scores and entity results from Comprehend sound more useful than putting the document behind a model guardrail.