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
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 write it into the picture: Amazon Nova Canvas and the Amazon Titan Image Generator add an invisible watermark to every image, along with C2PA content credentials recording the model, the platform, and the task type. Bedrock’s watermark detection, a public preview in us-east-1 and us-west-2, takes an image and reports whether one of those two watermarks is present, with a confidence level. That turns “we think this came from our model” into a checkable answer. It says nothing about whether the image was appropriate; it establishes provenance only.
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, and both are on their way out. Titan Image Generator G1 v2 reached end of life on 30 June 2026. Nova Canvas is on Bedrock’s legacy list with an end-of-life date of 30 September 2026, and a legacy model is already closed to new customers, so a feature built today cannot pick either one. Detection still answers the question for the pictures those two models made. For everything else, 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. Each card names the service release it applies to, so a team adopting a service can read, and cite, what AWS said it was for at that point. 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 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 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 placing them is all that is needed here: guardrails are the enforcement layer rather than 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 measured bias and explainability reporting 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; guardrail content filters cover text and, where image filtering is generally available, images for the hate, insults, sexual and violence categories, while denied topics and sensitive-information filters read text; 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 eight responsible-AI dimensions AWS names, which an earlier run through them lists: fairness, explainability, privacy and security, safety, controllability, veracity and robustness, governance, and transparency. Watermarking and detection serve transparency. Service cards serve transparency and governance. Guardrails serve safety, controllability, and privacy and security. Model cards and bias reporting serve fairness, explainability, and governance. 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
- 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.
- Modality: is the artefact an image, text, or a document about a service or model?
- Timing: is it a design-time artefact you author and keep, or a runtime control that acts while generation happens?
- Scope: does it act on one output, or describe the service or model as a whole?
- Who produces it: AWS publishes it, or you author and maintain it?
The landscape
Watermarking and detection. Amazon’s own image models, Nova Canvas and the Titan Image Generator, add an invisible watermark to every image at generation time, plus C2PA content credentials in the file’s metadata. The watermark is not a visible overlay, and detection still finds it in an edited image, though AWS notes modification makes the result less accurate; the metadata, by contrast, can be stripped outright. Detection is a public preview in us-east-1 and us-west-2: hand it an image and it reports whether one of those two watermarks is present, with a confidence level. It establishes AI origin for a specific artefact and makes no judgement about content, appropriateness, or accuracy. What has changed is its supply. The Titan Image Generator went end-of-life on 30 June 2026 and Nova Canvas follows on 30 September 2026, so detection answers for the images those two 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 work 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, word filters, 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 bias measurement. 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. Bias and explainability metrics, pre-training and post-training bias measures, and feature-importance reporting populate the evaluation side of that record. SageMaker Clarify has been the tool that generated them; it closed to new customers on 30 July 2026, existing customers can carry on, and AWS plans no new features for it. A team already running Clarify keeps its reports. A team starting now computes the same published bias formulas itself and takes feature attribution from SHAP, the library Clarify’s explainability is built on. Clarify’s foundation-model evaluation lives on as the open-source fmeval library, with Bedrock evaluation jobs as the managed path, and AWS is explicit that neither covers bias detection for a tabular model. Together the card and the measurements 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, privacy and security, safety, controllability, veracity and robustness, governance, and transparency 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.
Evaluation
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 (preview) | 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 | Text; images in content filters | Runtime | Single call | You configure |
| Model card + bias measurement | 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 measured bias. Four asks, four separate responsibilities, and no control answers more than one of them.
The solution
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. The Titan Image Generator reached end of life on 30 June 2026, Nova Canvas reaches it on 30 September 2026 and is already closed to new customers, and an image feature built today runs on a model whose output detection cannot read. Where the archive holds output from the Amazon generators, detection remains a lookup you can run at any time, and it returns a confidence level rather than a bare yes, which matters when an image has been cropped or recompressed on its way through the publishing pipeline. That preview runs in us-east-1 and us-west-2.
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 from the record kept upstream, 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 drawback is that someone has to do it, at the moment of generation, for every image, which is the work the watermark used to handle automatically. 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 one this system has no evidence about, not proof of a real photograph.
The transparency ask is the service card, and it serves as evidence rather than reading material. The card is where AWS states the service’s intended use and its limitations, and each card names the service release it applies to, so the defensible record legal wants is a cited copy of the card current at 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, because enforcement has to happen while the response is being produced. A guardrail sits in the call and blocks or filters the output before it reaches the editor, invoked alongside an image model through InvokeModel. The two asks land on different policies. A violent scene is a content filter, which covers images for the hate, insults, sexual and violence categories in the Regions where image filtering is generally available. A real named person is not a filter category at all, so that one is a denied topic or a word filter applied to the prompt text, catching the request rather than inspecting the face. Because a guardrail changes what comes out, it carries operational weight: too loose and bad outputs slip through, too tight and legitimate scenes get blocked.
The churn model’s documentation is the model card, populated by measured bias. 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. Where the group already runs Clarify, its pre-training and post-training bias metrics and feature-importance figures keep coming, because closing to new customers leaves existing ones running. Starting fresh, the team computes the published bias formulas itself and takes feature attribution from SHAP. Bedrock evaluation jobs and fmeval cover foundation models and do not answer a tabular question like this one. The model card is where the numbers 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.
Worked example
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 level, and a negative one tells you the picture came from somewhere else. For anything generated after the move off the Amazon generators, 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 in the request path: a content filter on the violence category for the scene, and a denied topic or word filter on the prompt for the named person, since likeness is not a filter category. 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 measured bias and explainability metrics, from an existing Clarify deployment where one is already running, or from the published formulas and SHAP where the team is starting now that Clarify is closed to new customers. 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.
What’s worth remembering
- 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.
- Provenance is a design decision taken upstream, because nothing can be retrofitted onto a picture after the fact; for a feature built today, with both watermarking Amazon generators at or near end of life, 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.
- 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.
- 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.
- Model cards document a model’s intended use and evaluation, populated by measured bias and explainability metrics; SageMaker Clarify supplied those and closed to new customers on 30 July 2026 (existing customers carry on; a new team computes the published formulas itself and uses SHAP, since Bedrock evaluations and fmeval cover foundation models rather than tabular ones). Both card and metrics are design-time governance, not runtime controls.
- 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.