Nobody could answer. Not because anything was broken, but because the system had quietly stopped being a parser somewhere between the S3 upload and the sorted list on a recruiter’s screen. It had become a selection procedure, and nothing in it was designed to explain itself.

That is the failure mode worth leading with, because it never pages you. Your alarms stay green while the thing you built lands in a category of regulated system you never intended to build.

This post covers CV parsing on AWS as it actually goes: what Amazon Textract gives you and what it doesn’t, where Bedrock belongs and where it becomes a liability, the bias problem you have to document rather than solve, and the failures that only surface at volume.

When CV parsing on AWS becomes a hiring decision

Most of these pipelines start honestly. Someone wants structured JSON out of a PDF pile so the ATS populates fields instead of a coordinator retyping them. Extraction is a data problem with clean success criteria.

Then a product manager asks for a match score. It seems small. You already have the skills list and the job description, so you ask a model how well they line up and emit a number. The API contract barely changes.

What changed is everything. The moment a recruiter sorts by that number and works down from the top, the pipeline substantially assists a hiring decision. Under New York City’s Local Law 144 that is an automated employment decision tool, and the obligations attach to the employer using it, not the vendor who wrote the code. Under the EU AI Act, Annex III point 4 lists systems intended to analyse and filter job applications and evaluate candidates as high-risk by classification, not by how confident you are in your prompt.

The EU date is worth stating plainly because it moved. Annex III obligations were originally due to apply from 2 August 2026; the Digital Omnibus package pushed stand-alone Annex III systems out to 2 December 2027. That is a reprieve on paperwork, not on design. Systems procured now will still be running then, and the separate prohibition on workplace emotion-recognition AI, plus existing GDPR duties around automated decisions, were never on that timetable.

So the first architectural decision isn’t about services. It’s about where extraction stops and judgement begins, and whether that boundary is visible in the code or buried in a prompt.

Getting text out: what Textract actually does

Textract is good at CVs in a narrow way. It reads printed and handwritten text, detects tables and form-style key-value pairs, and with the Layout feature type it identifies structural elements such as titles, paragraphs, lists, headers and footers. For a two-column CV with a skills sidebar, layout awareness is the difference between usable text and word salad.

Sync versus async is not a performance choice

AnalyzeDocument is synchronous and takes a single image or a document passed as bytes or an S3 object. StartDocumentAnalysis is the asynchronous entry point for multipage documents; it publishes completion status to an SNS topic you drain from SQS before calling GetDocumentAnalysis with the returned job ID.

People pick sync because it’s easier to reason about, then discover half of real CVs are three pages. Go async from the start. The SNS-to-SQS hop isn’t overhead, it’s the only thing that gives you a retry surface when a job fails partway through a batch.

Queries beat walking the block graph by hand

The Queries feature lets you ask natural-language questions of a document without knowing where the data sits on the page. Pass QUERIES in FeatureTypes, supply a QueriesConfig, then read the QUERY_RESULT blocks out of the response.

aws textract start-document-analysis 
  --document '{"S3Object":{"Bucket":"bucket","Name":"document"}}' 
  --feature-types '["QUERIES"]' 
  --queries-config '{"Queries":[{"Text":"Question"}]}'

Each query can carry an alias so answers map back to your schema without positional guessing. In Python, walk the returned blocks and pick the ones whose BlockType is QUERY_RESULT, each carrying answer text and a confidence score.

response = client.analyze_document(
    Document={'S3Object': {'Bucket': bucket, 'Name': document}},
    FeatureTypes=["TABLES", "FORMS", "QUERIES"],
    QueriesConfig={'Queries': [{'Text': question}]}
)

for block in response['Blocks']:
    if block["BlockType"] == "QUERY_RESULT":
        print(block["Text"])

Use Queries for facts that exist verbatim on the page: employer name, job title, dates, certification number. Not for anything requiring inference. “What is this person’s seniority level?” is a judgement, and pushing it through an extraction API hides that judgement inside something that looks like OCR.

Where Bedrock belongs, and where it stops

Bedrock earns its place in one job: turning messy extracted text into a consistent schema. CVs are the worst kind of semi-structured document because the structure is a fashion trend. One person lists dates as “Mar 2019 to present,” another renders them as a bar chart. Normalising that is exactly the fuzzy transformation a language model handles well, and one you can verify.

1. Constrain output to a schema and reject anything that fails validation. A job title you didn’t ask for, or an employment date absent from the source text, is a failed record rather than a creative flourish.
2. Turn on model invocation logging before you process a single real CV. It’s disabled by default, and it’s the only native record of what you sent and what came back.

That second point isn’t a nice-to-have. When someone asks a year from now why a candidate scored the way they did, the invocation log is your answer or you don’t have one.

aws bedrock put-model-invocation-logging-configuration 
  --logging-config '{
    "s3Config": {"bucketName": "my-bedrock-logs", "keyPrefix": "cv-pipeline/"},
    "textDataDeliveryEnabled": true
  }'

Logs go to CloudWatch Logs, S3, or both, and only destinations in the same account and Region are supported. Apply lifecycle rules and encryption up front, because these logs contain full CVs and they outlive the hiring round that produced them.

Bedrock Guardrails fits here through sensitive information filters, which detect PII in prompts and responses and either block the payload or mask individual entities with identifier tags. There’s a detect mode that reports what a guardrail would have caught without acting, which is the right way to tune against real documents first. Don’t oversell it to yourself: masking is not anonymisation, and a filter firing on NAME and EMAIL does very little about bias, for reasons that are the whole point of the next section.

The bias problem you must document, not solve

Every engineer’s instinct is to strip the protected attributes and declare it handled. Remove the name, the photo, the address, and the model can’t discriminate on what it can’t see. It doesn’t work, and understanding why separates a pipeline you can defend from one you can’t.

Proxies survive redaction

A CV is dense with correlated signal. University name tracks geography and socioeconomics. Graduation year is an age proxy that survives every name redaction you can write. Employment gaps correlate with caregiving. Postcode correlates with almost everything. Add professional association membership, the language a qualification is written in, whether military service appears, the phrasing conventions of a non-native English speaker.

None of those are protected attributes. All of them carry information about protected attributes, and a model optimising for similarity to your existing successful hires will use them. Redaction removes the label, not the signal, and it makes disparity harder to detect because you deleted the field you would have measured against.

You can’t prove a screening pipeline is unbiased. You can measure its outcomes, record what you measured, and act when the numbers move.

What the four-fifths rule actually asks for

The Uniform Guidelines on Employee Selection Procedures set out the rule of thumb federal enforcement agencies apply: a selection rate for any race, sex or ethnic group falling below four-fifths of the rate for the highest group is generally treated as evidence of adverse impact. It sits at 29 CFR 1607.4(D).

• It’s a rule of thumb, not a safe harbour. The same guidelines note smaller differences can still constitute adverse impact where they’re significant in statistical and practical terms, and courts have declined to treat clearing 0.8 as proof nothing is wrong.
• It applies to the selection procedure. That means your parser, your scorer and the recruiter’s sort order taken together. Auditing the model in isolation measures the wrong thing.

The computation is trivial, which is why there’s no excuse for skipping it.

SELECT
  demographic_group,
  COUNT(*) AS applicants,
  SUM(CASE WHEN advanced THEN 1 ELSE 0 END) AS selected,
  1.0 * SUM(CASE WHEN advanced THEN 1 ELSE 0 END) / COUNT(*) AS selection_rate
FROM screening_outcomes
WHERE requisition_id = :req
GROUP BY demographic_group;

Divide each selection rate by the largest and you have the impact ratio. Anything under 0.8 is a signal to stop and look, not a number to explain away.

Where the demographic data comes from

This is the genuinely hard part and where most teams stall. You need demographic data to measure disparity, and you must not feed it into the screening decision. The pattern that works is a strict split: self-reported responses collected separately at application time, stored in a different bucket under a different KMS key, joined to outcomes only in an analysis account the scoring pipeline has no path to.

NYC’s regime allows historical or test data, and requires the audit be performed by someone not involved in using or developing the tool. That independence requirement is easy to miss when you’re the consultant who built the thing. You can build the measurement harness. You can’t be the independent auditor of your own pipeline.

Document the pipeline, not the model

The artifact that saves you is boring and written down. At minimum: which model and version produced scores in each date range, the scoring logic in force, every field that reached the scorer, every field withheld and why, where human review sits and what a reviewer can override, and the impact ratios from each measurement run.

Keep it in version control beside the infrastructure code. A change to the prompt is a change to the selection procedure and should be reviewable as one.

Problems that only appear at volume

• Throttling arrives as data loss. Without retries using exponential backoff and jitter, a throttled call becomes a missing candidate rather than an error anyone sees. Assert on record counts at every stage boundary.
• Duplicates are the norm. The same person applies to three roles with two slightly different files. Deduplicate on content hash before you spend on extraction, and keep an idempotency key so a retried job doesn’t create a second candidate record.
• Cost is dominated by re-runs. Extraction is the expensive step and it’s deterministic on the same input. Store the raw Textract response in S3 keyed by document hash. Reprocessing after a schema change should cost storage, not inference.
• Retention outlives the requisition. Extracted text, invocation logs and intermediate JSON all contain personal data and all quietly accumulate. Set lifecycle rules at build time, not after the first data subject request.
• Scanned CVs are a different pipeline. Photographed documents behave nothing like exported PDFs. Route them separately with lower confidence thresholds and higher review rates.

On cost visibility, native tooling shows the shape of spend but is slow to attribute it. If this runs alongside other AI workloads, a dedicated platform such as Vantage or CloudZero makes per-pipeline attribution less painful than slicing Cost Explorer by tag every month. And if the upload front door is public, putting Cloudflare in front of it deals with bot traffic before it becomes Textract spend.

Troubleshooting

• High confidence, wrong fields. Almost always multi-column layouts read in the wrong order. Add the Layout feature type and check reading order in the block graph against what a human sees.
• Async jobs complete but results never arrive. Check the SNS topic policy allows publishing to your queue and that the role passed to Textract can publish. This fails silently and looks like a stuck pipeline.
• The model invents employment history. Your prompt is asking it to summarise rather than extract. Constrain the schema, require every value trace to source text, and fail validation instead of accepting a plausible answer.
• Scores shift after a model update. Pin the model identifier rather than tracking a moving alias, and re-run your measurement set against a held-out corpus before promoting any change.
• Guardrails block legitimate CVs. Sensitive information filters are probabilistic and context-dependent. Run detect mode against a real corpus and read the traces before switching to block.

Common mistakes

• Treating a match score as a data field rather than a decision, and skipping the governance that follows.
• Redacting names and considering the bias question closed.
• Enabling invocation logging after the pilot, leaving the first thousand decisions with no record.
• Building human review that only sees the shortlist, which reviews the output of the bias rather than the bias.
• Assuming a US-headquartered employer is out of scope. Both regimes reach based on where the candidate is, not where the company is.

Best practices

• Draw a hard line between extraction and scoring: separate services, separate IAM roles, separate logs.
• Enable model invocation logging before the first real document, with encryption and lifecycle rules already applied.
• Cache raw extraction output keyed by document hash so reprocessing never re-bills inference.
• Collect demographic data separately, key it differently, and join it to outcomes only in an isolated analysis account.
• Run impact ratios on a schedule rather than on request, and alert on movement instead of waiting for an audit.
• Version prompts and scoring logic in the same repository as the infrastructure, reviewed as changes to a selection procedure.

Frequently asked questions

Is Textract or Bedrock the right tool for CV parsing?

Both, for different halves. Textract turns pixels into text with layout awareness and confidence scores. Bedrock turns that text into a consistent schema. Using a language model for the OCR step gives up per-field confidence, which is exactly the signal you need to decide what goes to human review.

Does removing names and photos make a resume screening pipeline compliant?

No. Redaction handles direct identifiers while leaving proxies such as graduation year, institution, postcode and employment gaps intact. It also removes the fields you’d need to measure disparity, so it can make a pipeline harder to audit while feeling safer.

Do these rules apply if my company isn’t in New York or the EU?

Possibly. Local Law 144 turns on whether the candidate resides in New York City, including for remote roles, rather than where the employer sits. The EU AI Act has similar extraterritorial reach. Check with counsel, not with an architecture diagram.

Can I run the bias audit myself?

You can build the measurement pipeline and run it continuously, and you should. The formal NYC bias audit has to be performed by an independent party not involved in using or developing the tool, which rules out the team that built it.

How do I keep extraction costs predictable at scale?

Deduplicate before extraction, cache raw responses by content hash, and choose feature types deliberately. Requesting tables, forms and queries on every document when you only need queries multiplies cost for nothing. Both services bill per unit of work, so the lever is doing less work rather than finding a cheaper tier.

Should the pipeline auto-reject candidates?

Treat that as a question for counsel, not engineering. GDPR restricts solely automated decisions with significant effects on individuals, and the practical answer in most designs is a meaningful human review before any rejection. Build the human step in early; retrofitting it is painful.

The one thing worth remembering

CV parsing on AWS is two systems wearing one name. The extraction half is an engineering problem with clean success criteria, and Textract plus Bedrock will carry you a long way given retries, caching and schema validation. The scoring half is a selection procedure, governed by rules that don’t care what you called the service.

You won’t eliminate bias from a system trained on hiring history. What you can do is know where the boundary sits, log what crossed it, measure outcomes on a schedule, and be able to answer the question about candidate 4,412 when it arrives. Build the documentation while you build the pipeline. Reconstructing it later from CloudWatch and memory is a much worse job.

Work with me on document pipelines and AI governance

Most of the work here isn’t the extraction. It’s the boundary drawing, the evidence trail and the parts that only break at volume. Things I help with:

• Designing Textract and Bedrock pipelines with an auditable split between extraction and any scoring or ranking step.
• Building the measurement harness that computes selection rates and impact ratios on a schedule, with demographic data isolated from the scoring path.
• Setting up model invocation logging, retention, encryption and access controls so the evidence trail exists before you need it.
• Fixing throughput and cost problems: throttling, deduplication, extraction caching and reprocessing that doesn’t re-bill inference.
• Adding human-in-the-loop review that routes on confidence and score bands, including sampled rejections rather than shortlists only.
• Writing the technical documentation an independent auditor or your legal team will actually ask for.

Send me a sample Textract response, a scoring prompt or an architecture sketch and I’ll tell you where the boundary is currently blurred.

The post CV Parsing at Scale on AWS: Textract, Bedrock, and the Bias You Have to Document appeared first on John Nessime.

This post is a practical guide to how I’d extract contract data with Amazon Bedrock: the clauses, parties, dates, and obligations that feed contract lifecycle tools, obligation trackers, and compliance dashboards. It covers the two build paths Bedrock gives you, how to design the extraction schema, the three failure families that produce confident wrong answers, and the validation layer that catches them before they reach a system someone trusts.

Two ways to extract contract data with Amazon Bedrock

Bedrock offers two genuinely different routes to the same destination, and picking the wrong one costs you either flexibility or months of pipeline plumbing you didn’t need to build.

Path one: call a model directly

You send the contract to a foundation model, typically Anthropic Claude, through the Converse or InvokeModel API, with a prompt and a schema describing the fields you want back. Converse accepts PDF documents as a content block, so contract bytes go straight from S3 without a separate OCR step. One detail that catches people: full visual understanding of a PDF through Converse with Claude requires citations to be enabled. Without them the API falls back to plain text extraction, and anything living in a table or a scanned signature page silently disappears from the model’s view.

The piece that changed this path from fragile to dependable is structured outputs. Instead of asking the model nicely for JSON and writing defensive parsing code for the day it prepends an apology, you attach a JSON Schema to the request and Bedrock enforces it during token generation through constrained decoding. The response cannot fail to parse. One mechanic worth knowing: the first request with a new schema triggers a grammar compilation step, and compiled grammars are cached for a limited time, so schema churn has a latency cost.

Path two: Bedrock Data Automation

Bedrock Data Automation (BDA) is the managed intelligent document processing service. You define a blueprint, which is a list of fields with types and natural language instructions for how to find and normalize each one, attach it to a project, and invoke the async processing API against files in S3. BDA returns two things a raw model call does not give you out of the box: a confidence score per field and visual grounding, meaning bounding boxes pointing back to where on the page each value came from. A project can hold multiple document blueprints, so a mixed intake of NDAs, master service agreements, and amendments routes each document to the right extraction logic automatically.

My honest read on the choice: BDA wins when you want the boring parts managed and you need per-field confidence and grounding for a human review loop, which for contracts you almost always do. The direct model path wins when you need reasoning the blueprint format can’t express, like interpreting a clause against the definitions section. Plenty of real pipelines use both: BDA for the structured pass, a direct Claude call for the clauses that need interpretation. Amazon Textract still earns its place for high-volume standardized forms, but contracts are exactly the variable, long-tail documents layout-based extraction was never great at.

Design the schema before you touch the API

The schema is not a formality. With structured outputs, the field names, descriptions, and ordering you write become context the model generates against, so the schema is effectively part of the prompt. A vague schema produces structurally valid garbage: JSON that parses perfectly and means nothing.

Three design rules that pay for themselves. First, one concept per field: “renewal terms” as a single string is unusable downstream; split it into whether renewal exists, whether it is automatic, the duration, and the notice period to prevent it. Second, write field descriptions like instructions to a junior reviewer, including what the field is not. Third, make every field nullable and tell the model to return null when the contract is silent. A model forced to fill a required field will fill it with something.

Here is the shape I’d start with for a general commercial agreement, trimmed to the core:

{
  "type": "object",
  "properties": {
    "parties": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "legal_name": { "type": ["string", "null"],
            "description": "Full registered entity name from the preamble or signature block, not the defined shorthand" },
          "defined_term": { "type": ["string", "null"],
            "description": "The shorthand assigned in the preamble, e.g. Supplier, Client" },
          "role": { "type": ["string", "null"] }
        }
      }
    },
    "effective_date": { "type": ["string", "null"],
      "description": "Date the agreement takes effect. Null if only a signature date exists." },
    "governing_law": { "type": ["string", "null"] },
    "obligations": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "obligor": { "type": ["string", "null"] },
          "description": { "type": ["string", "null"] },
          "deadline_text": { "type": ["string", "null"],
            "description": "The deadline exactly as written, e.g. within 30 days of the Effective Date" },
          "source_clause": { "type": ["string", "null"],
            "description": "Section number where this obligation appears" }
        }
      }
    }
  }
}

Notice deadline_text keeps the deadline as written instead of asking the model to compute a calendar date. That is deliberate, and the reason is the second failure family below.

Failure family one: parties that aren’t who they say they are

Contracts name their parties once, in the preamble, then never again. From that point on everything refers to “the Supplier” or “the Receiving Party.” A naive extraction returns the defined term as the party name, which is useless for matching against a vendor master or a CRM. Worse, the signature block sometimes names a different legal entity than the preamble, usually an affiliate signing on behalf of a subsidiary, and the model will happily pick whichever it saw last.

The fix is structural, not clever prompting. Extract the legal name and the defined term as separate fields, as in the schema above, with instructions to take legal names from the preamble and cross-check the signature block. Then validate outside the model: if the two entities differ, flag the document for review rather than picking one. That mismatch is occasionally a genuine drafting error in the contract itself, which makes it exactly the kind of thing you want surfaced, not smoothed over.

Failure family two: dates that mean different things

A contract carries several dates that look interchangeable and are not: execution, effective, commencement, expiry, and the deadlines derived from notice periods. The extraction failure that costs money is almost never a misread date string. It is a correctly read date assigned to the wrong concept, or a relative deadline flattened into a wrong absolute one.

Relative dates are the invisible one. “Either party may terminate by written notice no later than ninety days before the end of the then-current term” contains no date at all. If your schema demands a date type, the model computes one, and its arithmetic rests on assumptions about the term start that may be wrong, especially when an amendment has reset the term. That computed date looks exactly as trustworthy in your tracker as a real one. This is why I extract deadline language verbatim and compute calendar dates in code, where the arithmetic is testable and the inputs are auditable.

Cheap validation catches most of the rest. The effective date must not fall after the expiry. A notice period must be a plausible number of days. If the agreement auto-renews, a renewal duration should exist. Fields that fail these checks get flagged. None of this needs a model; it is twenty lines of code standing between extraction and the systems people trust.

Failure family three: obligations, cross-references, and the amendment problem

Obligations are the hardest target because they are relational. “The Supplier shall deliver the reports described in Schedule 3 within the period set out in Section 4.2, except as provided in Section 9” is one obligation spread across three locations. Chunk the contract carelessly and the model sees the reference with no Section 4.2 in sight. It will either drop the deadline or invent a plausible one, and the second outcome is far worse because nothing downstream looks broken.

Contracts resist chunking more than almost any other document type, because defined terms and cross-references make every section depend on distant ones. The practical answers, in order of preference:

1. Don’t chunk. Modern model context windows fit most commercial agreements whole, and whole-document extraction is the single biggest accuracy win available. Reach for chunking only when a document genuinely doesn’t fit.
2. If you must split, prepend the definitions section and the table of contents to every chunk, and split on section boundaries rather than fixed token counts so no clause straddles a cut.
3. Capture the source clause reference for every obligation, as in the schema above, so a reviewer can jump straight to the language instead of re-reading the contract.

Then there are amendments. An amendment is a short document that quietly rewrites the base agreement, and if you extract each file independently your dataset will assert the original terms with full confidence long after they stopped being true. Treat the contract family, not the file, as the unit of extraction: process the base agreement, process each amendment, and resolve them in order so later documents override earlier ones. BDA’s multi-blueprint routing helps here, since amendments have a recognizably different shape and can carry their own blueprint focused on what changed.

The validation layer that makes it trustworthy

Schema compliance tells you the output is well-formed. It says nothing about whether it is true. The trust comes from three checks layered after extraction.

• Cross-field consistency. Dates in order, notice periods plausible, every obligation carrying an obligor that matches an extracted party. Pure code, no model.
• Grounding. Every extracted value should point back to a location in the document. BDA gives you this natively through bounding boxes; on the direct model path, requiring a source clause reference per field is the lightweight version. A value that cannot be traced to the page is a value you cannot audit.
• Confidence-based routing. Use BDA’s per-field confidence scores to route low-confidence extractions to human review and let high-confidence ones flow through. The goal is not eliminating review; it is spending reviewer minutes only where the model is unsure. Party names and governing law typically extract very reliably, while obligations from unusual templates are where automation honestly ends and review begins.

Operationally this looks like S3 event notifications triggering a Step Functions workflow: extract, validate, then branch to auto-accept or a review queue. Instrument it from day one. Track the auto-accept rate, per-field confidence distributions, and validation failure counts; a slow drift in confidence is usually the first sign a new contract template has entered the intake. I ship these to Grafana Cloud with the rest of the pipeline metrics, and since direct model calls bill by tokens while BDA bills per unit of content processed, a cost dashboard in something like Vantage or CloudZero shows quickly whether whole-document extraction is worth its token count for your mix. It usually is.

Troubleshooting

Fields come back null for content that is clearly in the document. On the Converse path with PDFs, check whether you are getting text-only extraction; content in tables, stamps, or scanned pages needs the visual analysis mode. For scans, verify image quality before blaming the model.

The same contract extracts differently on reruns. Set temperature to zero for extraction work, then look for instructions the model can resolve more than one way. Ambiguity in a schema description is the usual culprit.

First requests with a new schema are slow. That is grammar compilation for structured outputs. Stabilize your schemas and warm them before batch runs rather than generating schemas dynamically per request.

BDA accuracy is mediocre on your templates. Blueprint instructions are tunable, and BDA can refine them automatically from a small set of example documents with known correct values. Feed it your hardest real examples, not your cleanest ones.

Common mistakes

• Treating schema-valid JSON as verified data. Structure and truth are separate properties, and the second one needs its own checks.
• Extracting the defined term as the party name and matching it against vendor records.
• Letting the model compute calendar dates from relative deadline language instead of extracting the language and computing in code.
• Chunking by token count through a document whose clauses reference each other across fifty pages.
• Processing amendments as standalone documents and silently keeping stale base-agreement terms.
• Making every schema field required, which converts “the contract is silent” into a fabricated answer.

Best practices

• Extract whole documents whenever the context window allows. Every chunking strategy is a workaround, not a feature.
• Keep a small labeled evaluation set of your own contracts and score every prompt or blueprint change against it before shipping.
• Require a source reference for every extracted value, whether that is a BDA bounding box or a clause number from the model.
• Route on confidence and validation results, and measure your auto-accept rate as a first-class metric.
• Version your schemas and store the schema version alongside every extraction, so you can tell which records predate a fix.
• Keep humans in the loop for high-stakes fields. The realistic goal is automating the bulk and focusing legal review, not replacing it.

FAQ

Should I use Bedrock Data Automation or call Claude directly for contract extraction?

BDA if you want managed parsing, per-field confidence scores, and visual grounding for a review workflow. Direct model calls if you need interpretive reasoning over clauses or conversational access to the document. Many production pipelines combine both.

Do I still need Amazon Textract?

Usually not as the primary extractor for contracts, since layout-based extraction struggles with variable legal drafting. It remains a good fit for high-volume standardized forms, and some pipelines route documents between Textract and generative extraction by type.

How accurate is contract data extraction in practice?

It varies sharply by field type. Parties, governing law, and explicit dates extract reliably. Obligations, renewal mechanics, and anything expressed through cross-references are meaningfully harder, which is why confidence routing and human review exist. Distrust any vendor quoting one accuracy number for “contracts.”

How do I extract obligations specifically, not just metadata?

Model each obligation as its own object with obligor, description, deadline language, and source clause. Extract against the whole document so cross-references resolve, and validate that every obligor matches an extracted party.

Can Bedrock handle scanned contracts?

Yes. BDA processes scanned documents as part of its parsing stage, and Claude’s visual document understanding reads scanned pages when invoked with visual analysis. Scan quality still matters; poor scans degrade every approach.

Is it safe to put contracts through Bedrock?

Bedrock runs within your AWS account boundary, and AWS states that customer content is not used to train the underlying models. For sensitive agreements the usual controls apply: VPC endpoints for private connectivity, KMS encryption on the buckets, and IAM scoped to the pipeline roles. Confirm the specifics against your own compliance requirements.

Conclusion

If you remember one thing, make it this: when you extract contract data with Amazon Bedrock, valid output is the starting line, not the finish. Structured outputs and BDA blueprints have genuinely solved the formatting problem, which means the remaining risk is concentrated in meaning: the wrong entity, the wrong date concept, the obligation whose deadline lives two sections away. Design the schema around those failures, validate outside the model, ground every value to the page, and route on confidence. That is the difference between a demo and a pipeline a legal team will actually trust.

Need help building a contract extraction pipeline on AWS?

I design and build document intelligence pipelines on AWS as a freelance DevOps engineer. If you’re extracting data from contracts or other legal documents, here’s what I can help with:

• Designing extraction schemas and BDA blueprints for your actual contract types, including amendments and multi-document families
• Building the full serverless pipeline: S3 intake, Step Functions orchestration, extraction, validation, and review routing
• Adding the validation and grounding layer that catches confident wrong answers before they reach your CLM or tracker
• Setting up evaluation sets and accuracy measurement so prompt and blueprint changes are tested, not guessed
• Locking down the security side: VPC endpoints, KMS encryption, and IAM scoping for sensitive documents
• Cost tuning across model choice, whole-document versus chunked extraction, and BDA versus direct model calls

Send me a sample contract (redacted is fine), your target field list, or the output of a pipeline that isn’t behaving, and I’ll tell you what I’d do with it.

The post Extracting Clauses, Parties, Dates and Obligations with Amazon Bedrock appeared first on John Nessime.