2026 Steam AI Content Disclosure Guide: How to Describe Pre-Generated Content, Live-Generated Content, and Guardrails

Steam’s concern is not whether a team has used any software with AI features, but whether the content players consume was created with generative AI assistance, or whether content is generated while the game is running. The former is pre-generated content; the latter is live-generated content. Live-generated content also requires an explanation of the Guardrails that prevent illegal content.

For artwork, audio, narrative, localization, and other content generated during development and shipped with the game, describe the specific asset types, human review, rights verification, and version records. Do not simply write “AI improves efficiency,” or use “for assistance only” to conceal generated content that players will see.

We use [tool/workflow] to help generate [asset types].
All outputs enter the build only after [responsible person] completes a review of [rights, safety, and quality].
Final assets and version records are stored at [location].

Open-ended dialogue, images, storylines, or speech generated while the game is running count as live-generated content. In addition to the rules for pre-generated content, clearly describe input restrictions, context isolation, model safety settings, output checks, failure fallbacks, logging, and report handling.

“Uses industry-standard filters” is not specific enough. Reviewers need to understand each control point and how to access the feature to test it.

• The AI asset register identifies each asset’s purpose, source, and reviewer;
• Store disclosures match the actual build;
• Test accounts can access live-generation features;
• Jailbreaks, sensitive content, and service interruptions have been tested;
• Rights to third-party models, assets, and voices are documented;
• Contact Steam when updating how content is generated.

Disclosure does not automatically permit any content. Steam still requires content to be legal, non-infringing, and consistent with its marketing. The safest approach is to treat the Content Survey as part of product design, rather than the last form to fill out before launch.

Pre-generated content is text, images, video, speech, or code that the team creates with AI, selects, and packages into the game before release. It can be checked item by item before submission, but the use of tools and human review must still be explained. Live generation produces new outputs while players are playing. Its risks come not only from the assets themselves, but also from combinations of inputs, context leakage, model updates, and service interruptions, so additional descriptions of safeguards are required.

A single project may contain both types of content. For example, a background image generated during development and then manually retouched is pre-generated content; an NPC that responds immediately to a player’s free-form input is live-generated content. Do not lump the two together under “development assistance,” or overlook the generation process because the final output is exported as video. The more accurate the classification, the easier it is to keep the scope of internal testing consistent with store disclosures.

At a minimum, the register should record the asset ID, scene, content type, tool and version used, sources of input materials, generation date, manual edits, reviewer, basis for licensing, and final file location. If a voice involves an actor’s authorization, also record whether the authorization covers training, conversion, commercial release, and subsequent updates. When third-party materials are added to a reference image set, their licenses must also be confirmed; saving download links alone is not enough.

When the model, provider, or generation method changes, create a new asset version and determine whether the disclosure needs updating. This makes it easier to respond to platform inquiries and quickly identify affected shots when rights or quality risks are discovered, without rechecking the entire project.

First, limit the permitted input length, languages, and content types, then decide whether filtering takes place at the input stage, during generation, or at the output stage. Sensitive scenarios require multiple layers of control: system instructions define clear role boundaries, input filtering blocks obvious abuse, output checks intercept noncompliant content, and timeouts or refusals return fixed dialogue that has been reviewed. The plan should also specify how users can report issues, how long logs are retained, and who is responsible for manual handling.

Testing must go beyond ordinary dialogue. It should also cover prompt injection, attempts to manipulate the character’s role, spelling variants, multilingual bypasses, repeated follow-up questions, personal information, imitation of copyrighted characters, and network disconnections. Record the expected and actual results for each risk category. If an output cannot be reliably controlled, reduce the freedom available or switch to pre-generated options, rather than leaving the uncertainty to players and reviewers.

Before submission, have someone who did not help complete the survey enter the build from the store page and locate each feature based on the disclosure. They should be able to answer where AI appears, whether players can enter free-form input, how exceptions are handled, and who is responsible for review. Screenshots, test accounts, and reproduction steps must correspond to the current version. Promotional pages should use the same descriptions, avoiding a situation where the store says “only assists with backgrounds” while core characters actually generate dialogue in real time.

Platform rules may change, so recheck the official documentation before every major version release and record the date of the check. This article provides a workflow; it does not replace Steam’s current requirements or legal advice.

• Steamworks Documentation: Content Survey (Checked: 2026-09-22)