India Rule 3(3): metadata, identifier and no-removal for AI media

India's amended IT Rules, notified on 10 February 2026, say an intermediary that offers a tool able to create synthetic media must label the output prominently and, to the extent technically feasible, embed permanent metadata with a unique identifier of the tool, and must not let anyone remove the label or metadata. If you build on a generation API, the check for your pipeline is whether that identifier survives your own edits. This is not legal advice, and whether a given company counts as an intermediary is a legal question.

What the rule text says

The source is the consolidated rules on the Ministry of Electronics and Information Technology (MeitY) site, marked updated as on 10.02.2026, with the synthetic-media provisions inserted by G.S.R. 120(E) of that date. The table quotes the substance of the new Rule 3(3), which applies to an intermediary offering a computer resource that may enable the creation, modification or sharing of synthetically generated information.

Two details matter in practice. First, the metadata duty is qualified by 'to the extent technically feasible' and allows 'other appropriate technical provenance mechanisms', so it is not a single named standard. Second, the definition of synthetic media carves out routine or good-faith editing, formatting, colour adjustment, noise reduction, transcription or compression that does not materially alter the substance, which is the subject of the earlier post on routine editing.

What Sume's docs say about it

I searched the Sume docs for C2PA, watermark, Content Credentials and SynthID and found no statement that Sume embeds a provenance marker or identifier in generated files. Sume docs do not state it either way, so treat the delivered file as unmarked until you have inspected it. The docs do give you three things to build around:

• The Video 1.0 route, and several other routes in the docs, accept a metadata object that Sume stores on the job and does not send to the provider. It lives in your job record, not inside the video file
• Video trim in its default exact mode is a frame-accurate libx264 re-encode that returns a new artifact, never the source; keyframe mode is a stream copy
• Video filter runs worker ffmpeg only, with no provider inference, and also returns a new file

A check you can run on every delivered file

After any trim, filter or caption step, read the container tags of the file you will hand over and compare them with the file before the edit. If a tag or identifier your provider wrote is present before and gone after, you have found the loss yourself instead of discovering it in a review. The command reads tags only:

ffprobe -v error -show_entries format_tags:stream_tags -of json delivered.mp4

Keep three records per file: the Sume job ID, the Idempotency-Key you sent, and your own label status stored in the metadata object. That gives you something to show if a platform or customer asks how a clip was made and whether a visible label was added.

What to do in a pipeline

The list below is the working order for a pipeline.

• Add a visible label to anything that is realistic AI media you publish in India, burned into the frame, since your edit cannot strip it
• Prefer keyframe stream copy over exact re-encode for plain cuts when frame accuracy is not needed, and re-run the ffprobe check either way
• Never write a step that deliberately clears tags or identifiers on AI media
• Ask your generation vendor in writing what they embed; Sume's docs do not say

Rule 3(3)(b) speaks to the intermediary offering the tool, not to every downstream editor, but removing a marker in your own pipeline is the easiest way to end up arguing about it. Read the rule text on the MeitY page and take advice for your own case.