Proving Where AI Content Came From

The situation

A media company has built an image feature on Amazon Bedrock. Editors describe a scene, an image model generates it, and the picture drops into an article. Legal now wants three things before it goes live. They want to be able to answer, months later, whether a given picture in the archive was machine-generated or a real photograph. They want a defensible record that the team understood what the image service was designed for and where it falls short. And they want a way to stop the feature emitting a face that looks like a real named person, or a violent scene, at the moment it happens rather than in a review afterwards.

Alongside the image work, a data-science group in the same company runs a churn model and a text-classification model, and their compliance reviewer keeps asking for documentation of intended use, training data, and measured bias for anything that ships. The two teams have started using the words interchangeably. Someone in a meeting asked for a watermark to prove the churn model was fair, and someone else asked whether a service card would stop the image model drawing a celebrity.

These are four separate responsibilities, and each is discharged by a different mechanism. Proving an output’s origin is not the same as documenting a service’s limits, which is not the same as enforcing behaviour at runtime, which is not the same as reporting a model’s evaluation. The failure here is category confusion: reaching for the control that sounds responsible instead of the one that answers the question in front of you.

What actually matters

The first thing worth separating is what you are trying to establish. There is a real difference between proving something about a single output, providing transparency about a service or model in general, enforcing a rule while generation happens, and documenting how a model was built and judged. Those are four questions, and no single artefact answers more than one of them well.

Proving origin is a claim about a specific artefact after the fact. Given this image, did our model make it? That is only answerable if something was written down at generation time that you can later match back to the picture. Amazon’s own image generators put it inside the picture itself: Amazon Nova Canvas and the Amazon Titan Image Generator embed an invisible, tamper-resistant watermark in every image they produce, and Bedrock exposes a detection capability that inspects an image and reports whether it carries one of these watermarks, with a confidence score. That turns “we think this came from our model” into a checkable answer, and it says nothing about whether the image was appropriate; it only establishes provenance.

How far that answer reaches is the part the archive question turns on, and it has narrowed. The watermark was only ever a feature of Amazon’s own generators. Nova Canvas sits on Bedrock’s legacy list now, the Titan Image Generator has been removed from the catalogue altogether, and the third-party image models that carry text-to-image today embed nothing for detection to find. Detection still answers the question for pictures those Amazon models made, and it will keep answering it. For anything generated since, the record has to be one your pipeline writes as the image is created, which is the version of this control that survives a model’s lifecycle rather than ending with it.

Providing transparency about a service is a design-time claim about the thing in general, not about any one output. AWS AI Service Cards are published documents that describe an AI service or model’s intended use cases, design and fairness choices, limitations, and responsible-use guidance. They exist so that a team adopting a service can read, and cite, what AWS says it is for and where it should not be trusted. A service card is evidence that you understood the tool’s envelope; it does not touch a single generated image and it enforces nothing.

Enforcing behaviour is a runtime concern. A document, however honest, cannot stop a specific request producing a specific bad output. That is the job of a guardrail that sits in the request path and blocks, filters, or grounds the response as it is produced. Amazon Bedrock Guardrails apply content filters, denied topicsDenied topicsSubjects you describe in plain language that a Bedrock Guardrail refuses to discuss, whichever way a user phrases the request. , sensitive-information handling, and contextual grounding checksContextual grounding checkA Guardrail check that tests an answer against the documents it was given and flags claims the source doesn’t support. at the moment of the call. This is the only one of the four that changes what actually comes out. An earlier walk through of the runtime controls covers how guardrails and the trust boundary fit together, so the point here is just to place them: guardrails are the enforcement layer, not the documentation layer.

Documenting a model is governance about how it was built and how it performed. Model cards record a model’s intended use, training approach, and evaluation results, and bias and explainability reporting from Amazon SageMaker Clarify produces the fairness and feature-importance metrics that go inside them. This is what the data-science reviewer is actually asking for on the churn model: a documented, evaluated account of intended use and measured bias. It is an artefact you write and maintain, not something that acts at runtime and not something that proves the origin of one output.

Two cross-cutting facts hold the four together. Each control lands on one modality more naturally than the others: watermarking and its detection are an image-generation feature, guardrails act mostly on text (with image content controls a newer addition), service cards and model cards are documents about whatever they describe. And each control is either a design-time artefact you produce and keep, or a runtime control that acts during the call. Watermark detection is the interesting hybrid: the watermark is embedded at generation time, but you read it back on demand, long after. These two axes, what you are proving or providing and whether it acts at design time or runtime, sort the whole space.

It helps to place all of this against the broader responsible-AI dimensions a prior card lists: fairness, explainability, robustness, transparency, privacy, safety, controllability, and veracity. Watermarking and detection serve transparency and veracity about provenance. Service cards serve transparency. Guardrails serve safety, controllability, and privacy. Model cards and Clarify reporting serve fairness and explainability. The dimensions are the “why”; these controls are the “how”, and mapping one to the other is most of the skill.

What we’ll filter on

1. What you are trying to prove or provide: the provenance of a specific output, transparency about a service in general, enforcement of behaviour during the call, or documented governance of a model.
2. Modality: is the artefact an image, text, or a document about a service or model?
3. Timing: is it a design-time artefact you author and keep, or a runtime control that acts while generation happens?
4. Scope: does it act on one output, or describe the service or model as a whole?
5. Who produces it: AWS publishes it, or you author and maintain it?

The provenance landscape

Watermarking and detection. Amazon’s own image models, Nova Canvas and the Titan Image Generator, embed an invisible, tamper-resistant watermark into every image at generation time. It is not a visible overlay and it is designed to survive ordinary edits like cropping, compression, or resizing. Separately, Bedrock offers a detection capability: hand it an image and it reports whether the image carries one of these AWS watermarks, together with a confidence level. It proves AI origin about a specific artefact; it makes no judgement about content, appropriateness, or accuracy. What has changed is its supply. Nova Canvas is legacy, the Titan Image Generator is no longer listed in the catalogue at all, and the third-party models that carry text-to-image today embed nothing, so detection answers for the images those two Amazon models already made and for no others.

A provenance record you keep. The same question, answered from your side of the call. As each image is generated, the pipeline writes a row: the model id and version, the request id, the prompt, the account and feature that asked, and a hash of the bytes that shipped. Matching an archived picture back to that row establishes origin exactly as a watermark does, with two differences that cut in opposite directions. It works with any model, including every generator now carrying image work on Bedrock, and it keeps working when a model is retired. But it lives outside the artefact, so an image that leaves your pipeline and comes back cropped and recompressed has to be matched some other way, and a record nobody wrote at the time cannot be reconstructed later. It is design-time discipline rather than a service you enable.

AI Service Cards. Published by AWS, a service card is a transparency document for an AI service or model. It sets out intended use cases, the design and fairness considerations behind the service, known limitations, and guidance on using it responsibly. You read and cite one when you adopt a service, so that your own records show you understood its envelope. It is design-time, general to the service, and produced by AWS rather than you. It documents; it does not act.

Amazon Bedrock Guardrails. A runtime control that sits in the request path. It applies configurable content filters, denied-topic blocks, sensitive-information redaction, and contextual grounding checks that test a response against source material to catch unsupported claims. It is the only control here that changes the output that actually reaches the user, because it acts during the call. It enforces behaviour; it does not prove origin or document design.

Model cards and SageMaker Clarify. A model card is a governance document you author: it records a model’s intended use, how it was built, and how it was evaluated, including limitations. SageMaker Clarify generates the bias and explainability metrics, pre-training and post-training bias measures, and feature-importance reporting, that populate the evaluation side of that record. Together they document how a model was built and judged. They are design-time artefacts about a model as a whole, maintained by you, and they enforce nothing at runtime.

The responsible-AI dimensions. Fairness, explainability, robustness, transparency, privacy, safety, controllability, and veracity are the properties you are ultimately accountable for. They are not controls; they are the goals the controls above serve. Naming the dimension a stakeholder cares about is the fastest way to find the control that serves it.

Side by side

Control	What it establishes	Modality	Design-time or runtime	Scope	Produced by
Watermarking + detection	Provenance: this output is AI-generated	Image	Embedded at generation, read back on demand	Single output	Amazon generators embed, you check
Provenance record you keep	Provenance: this output came from our feature	Any	Written at generation, queried on demand	Single output	You author and keep
AI Service Card	Transparency about a service’s intended use and limits	Document	Design-time	Whole service	AWS
Bedrock Guardrails	Runtime enforcement of content and grounding rules	Mostly text, some image	Runtime	Single call	You configure
Model card + Clarify	Documented governance: intended use, bias, evaluation	Document (about a model)	Design-time	Whole model	You author
Responsible-AI dimensions	The properties you are accountable for	✗ (not a control)	✗	✗	Framework

Reading the table against the three legal asks: proving whether an archived picture was machine-generated is watermark detection for the images an Amazon generator made and the pipeline’s own record for everything else; showing the team understood the image service’s limits is the service card; stopping a real face or a violent scene at generation time is a guardrail. And the data-science reviewer’s request for documented intended use and measured bias on the churn model is a model card backed by Clarify. Four asks, four separate responsibilities, and no control answers more than one of them.

The picks in depth

The archive question is provenance, and the important nuance is timing. Whatever establishes origin has to be created at the same moment the image is, because there is no way to retrofit provenance onto a picture that was made elsewhere or made before the feature existed. That makes it a design decision taken upstream, and it is the decision most teams discover late.

For a stretch, Bedrock made that decision easy: point the feature at Nova Canvas or the Titan Image Generator and the watermark went in automatically, whether anyone had thought about the archive or not. That is no longer the arrangement on offer. Nova Canvas is legacy, the Titan Image Generator has been dropped from the catalogue, and an image feature built today runs on a third-party model that ships pictures with nothing embedded in them. Where the archive holds output from the Amazon generators, detection remains a lookup you can run at any time, and it returns a confidence rather than a bare yes, which matters when an image has been cropped or recompressed on its way through the publishing pipeline. That part of the archive is still answerable and always will be.

Everything generated since has to be covered by a record the pipeline writes itself: the model id and version, the request id, the prompt, and a hash of the bytes that shipped, stored where legal can query it. It answers the same question with the same upstream discipline, and it has the advantage of surviving the next lifecycle change, because it does not depend on which model the catalogue is offering this year. The cost is that it is work someone has to remember to do, at the moment of generation, for every image, which is precisely the work the watermark used to absorb. Neither mechanism judges the picture: a watermarked image can still be one the guardrail should have blocked, and an image with no watermark and no record is simply one this system cannot vouch for, not proof of a real photograph.

The transparency ask is the service card, and the discipline is to treat it as evidence rather than reading material. The card is where AWS states the service’s intended use and its limitations, so the defensible record legal wants is a cited reference to the current card, captured at the point of adoption, showing the team read the envelope before building inside it. It is design-time and it is about the service in general, so it never touches an individual image and it cannot be pointed at to explain why one specific output looked wrong. When someone asks the service card to stop a celebrity face appearing, the answer is that a document cannot stop anything; that is a different responsibility.

Stopping the face or the violent scene is the guardrail, and the reason it is the only fit is that enforcement has to happen while the response is being produced. A guardrail sits in the call, applies content controls and, where the modality supports it, image content filtering, and blocks or filters the output before it reaches the editor. It is configured by you, tuned to the categories that matter, and it acts per call. Because it changes what actually comes out, it is also the control that carries operational weight: too loose and bad outputs slip through, too tight and legitimate scenes get blocked. The runtime detail belongs to the earlier guardrails coverage; the placement point is that no document or watermark can substitute for a control in the request path.

The churn model’s documentation is the model card, populated by Clarify. This is squarely the data-science reviewer’s request: a written account of intended use plus measured bias and explainability, not a claim about any single prediction. Clarify computes the pre-training and post-training bias metrics and the feature-importance figures; the model card is where they live alongside the intended-use and limitation statements. It is design-time and about the model as a whole, which is exactly why a watermark would answer nothing here: there is no per-output artefact to stamp, and the question was never about origin. Fairness is documented and evaluated, not watermarked.

A worked example: four asks, four controls

Take the four requests as they actually arrived and route each one.

“Can you confirm this specific picture in last month’s article came from our generator?” This is provenance about a single output, and which mechanism answers it depends on when the picture was made. For the stretch when the feature ran on Nova Canvas or the Titan Image Generator, run Bedrock’s watermark detection against the image: a positive result confirms origin with a confidence, and a negative one tells you the picture came from somewhere else. For anything generated after the move to a third-party model, detection has nothing to read and a negative result means nothing, so the answer comes from the pipeline’s own record, matched on the hash of the bytes. A model card would say nothing about this image, and a guardrail acts only at generation, not on an image already in the archive.

“Show me we understood what this image service is and isn’t meant to do.” Transparency about the service. Cite the AI Service Card for the model, captured at adoption, covering intended use and limitations. No per-image artefact is involved, and no runtime control answers a “did we understand the tool” question.

“Make sure it never renders a real named person or a graphic scene.” Runtime enforcement. Configure a Bedrock Guardrail with the relevant content controls in the request path so the output is blocked or filtered as it is produced. A service card documents the risk but cannot prevent the output; only the guardrail acts during the call.

“Document the churn model’s intended use and its measured bias.” Governance documentation. Author a model card and populate its evaluation section with SageMaker Clarify’s bias and explainability metrics. This is a design-time artefact about the whole model; watermarking and guardrails have no role, because the question is neither about one output’s origin nor about runtime behaviour.

Four questions, four kinds of control, and the discipline is refusing to let a control that sounds responsible answer a question it structurally cannot.

What’s worth remembering

1. Proving an output’s origin, providing transparency about a service, enforcing behaviour at runtime, and documenting a model’s governance are four separate responsibilities, and each has its own AWS control.
2. Watermarking plus Bedrock detection proves an image was AI-generated; Amazon’s own generators, Nova Canvas and the Titan Image Generator, embed an invisible, tamper-resistant watermark, and detection reports presence with a confidence.
3. That watermark is an Amazon-generator feature, not a Bedrock-wide one: Nova Canvas is legacy, the Titan Image Generator is no longer in the catalogue, and third-party image models embed nothing, so detection answers only for the images those two already made.
4. Provenance is a design decision taken upstream, because nothing can be retrofitted onto a picture after the fact; for a feature built today that means a record the pipeline writes as it generates, holding the model id and version, request id, prompt, and a hash of the bytes.
5. A record you keep works with any model and survives the next deprecation, but it lives outside the artefact and only exists if someone wrote it at the time.
6. Neither mechanism judges the picture; establishing origin says nothing about whether the content was appropriate or accurate.
7. AI Service Cards are AWS-published documents describing a service’s intended use, design choices, and limitations; they provide transparency and are cited as evidence, but they enforce nothing.
8. Bedrock Guardrails are the only control that changes the output, because they act in the request path; a document cannot stop a specific bad generation.
9. Model cards document a model’s intended use and evaluation, and SageMaker Clarify supplies the bias and explainability metrics that populate them; both are design-time governance, not runtime controls.
10. Sort any control by two axes: what you are proving or providing, and whether it acts at design time or runtime; watermark detection is the hybrid, embedded early and read back on demand.
11. The responsible-AI dimensions (fairness, explainability, robustness, transparency, privacy, safety, controllability, veracity) are the goals; naming the dimension a stakeholder cares about points you at the control that serves it.
12. The recurring mistake is category confusion: asking a watermark to prove fairness or a service card to block an output; match the responsibility to the artefact that actually discharges it.