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 wrote it into the picture: the AI Service Cards for Amazon Nova Canvas and the Amazon Titan Image Generator both say the model applies an invisible watermark to every image it generates, and adds C2PA content credentials whose metadata carries the model, the platform, and the task type. The credentials read in any C2PA tool. The watermark is the problem: both cards say a detection solution can check for it, and the Bedrock user guide and API reference document no page, no operation and no Region for running one, so detection is a capability AWS asserts rather than one you can build on. Neither says anything about whether the image was appropriate; they establish provenance only.
How far that answer reaches has narrowed to nothing. The watermark was only ever a feature of Amazon’s own generators, and both are gone: Titan Image Generator G1 v2 reached end of life on 30 June 2026 and Nova Canvas on 30 September 2026, and after that date Bedrock removes a model from every Region and fails requests to it. For the pictures those two already made, the credentials still read until someone strips the metadata, and that is the only part of the embedded record AWS documents a way to read. Everything else has to rest on a record your pipeline writes as the image is created, which 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 content credentials are an image-generation feature; guardrail content filters cover text and, in the four Regions where image filtering is generally available, images for the hate, insults, sexual, violence, misconduct and prompt-attack 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. Embedded provenance is the interesting hybrid: the credentials go in at generation time, but you read them 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 content credentials 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 content credentials. Amazon’s own image models, Nova Canvas and the Titan Image Generator, added an invisible watermark to every image at generation time, plus C2PA content credentials in the file’s metadata. Neither is a visible overlay, and AWS points you at a public C2PA tool to read the credentials, with the caveat that removing the metadata removes the answer. The watermark is harder: both service cards say a detection solution can check for it, and nothing in the Bedrock user guide or API reference says how, where, or with what result, so there is no mechanism here to build an archive policy on. What there is establishes AI origin for a specific artefact and makes no judgement about content, appropriateness, or accuracy. The supply has gone too: Titan Image Generator went end-of-life on 30 June 2026 and Nova Canvas on 30 September 2026, so even the embedded record stops with the images those two already made.
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; AWS announced on 30 June 2026 that it is closed to new customers, 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 |
|---|---|---|---|---|---|
| Watermark + C2PA credentials | Provenance: this output is AI-generated | Image | Embedded at generation, credentials read on demand | Single output | Amazon’s retired generators embedded them |
| 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 the C2PA credentials, for the images an Amazon generator made that still carry their metadata, 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 and credentials went in automatically, whether anyone had thought about the archive or not. That is no longer the arrangement on offer. Titan Image Generator reached end of life on 30 June 2026 and Nova Canvas on 30 September 2026, so an image feature built today runs on a model whose documentation describes no embedded provenance. Where the archive holds output from the Amazon generators, the credentials are the part you can still read, for as long as the metadata survives the crop and recompress of a publishing pipeline. The watermark underneath is more durable and the one AWS gives no documented way to read.
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: an image carrying content credentials can still be one the guardrail should have blocked, and an image with no credentials 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, violence, misconduct and prompt-attack categories in the four Regions where image filtering is generally available, and the first four of those where it is still in preview. A real named person is not a filter category at all, and AWS steers names away from denied topics too: topic filtering evaluates a theme, and the guide names “statements or questions containing the name of a person” as a word-filter case. So that one is a custom word filter on the prompt text, a list of names matched exactly, 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, open the file in a C2PA tool: credentials naming the model and the task type confirm origin, and their absence means another source or a pipeline that stripped the metadata. For anything generated since, nothing was embedded, 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 custom word filter on the prompt for the named person, since likeness is not a filter category and AWS’s guide steers names away from denied topics. 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
- Four questions, four controls. Provenance, service transparency, runtime enforcement and model governance are separate responsibilities; no single AWS control answers more than one.
- Write provenance at generation. Nothing can be retrofitted onto a picture; record model id and version, request id, prompt and a hash of the bytes.
- Embedded provenance retired with the models. Titan ended 30 June 2026, Nova Canvas 30 September 2026; AWS documents no way to read their watermark.
- Service cards document; they enforce nothing. AWS publishes intended use and limitations per service release; cite them as evidence, never as a block on output.
- Only Guardrails change the output. They act in the request path; violence is a content filter, while a named person is a custom word filter.
- Model cards need measured bias. Clarify closed to new customers, announced 30 June 2026, so new teams compute the bias formulas themselves and use SHAP.