AI content disclosure, store policies and age ratings

Two kinds of AI content

Storefronts and rating bodies increasingly distinguish between two categories, and so should your documentation:

• Pre-generated content: anything made with AI tools during development that ships in the build: art, audio, text, code. It's fixed, so it can be reviewed like any other content.
• Live-generated content: anything created by a model while the game is running: dialogue, quests, images, voices. It can't be fully reviewed in advance, so platforms want to know what stops it producing harmful or illegal material.

Steam, the largest PC storefront, has asked developers since early 2024 to disclose both kinds on submission, and to describe guardrails for live-generated content. Disclosures appear on the store page, and players can report problematic generated content. Other storefronts and console platforms have their own policies, which change often, so check each platform's current developer documentation before submission.

What to document before submission

Whether a platform asks for one paragraph or a detailed questionnaire, we prepare the same internal document for every title. It makes submissions faster and gives rating bodies something concrete to review:

1. Inventory of AI use. Every place a model is used, pre-generated or live, with the model family and where it's hosted.
2. Human review process. For pre-generated content: who reviewed it and against what standard.
3. Guardrails for live content. System-level instructions, input filtering, output classification, banned topics, and what happens when a check fails.
4. Evaluation results. How you tested: red-team prompts, automated evals, playtests, and the measured failure rate.
5. Reporting and response. How players report bad output and how quickly you can update guardrails without a client patch.
6. Data handling. What player input is stored, for how long, whether it's used for training, and how that matches your privacy policy.

Age ratings with generative content

Age rating systems assess content: violence, language, sexual themes, gambling and so on. A conventional game's content is fixed. A game with live-generated dialogue could, in theory, produce anything. Rating bodies handle this differently and their guidance is evolving, but the practical approach is the same everywhere: define and enforce a rating envelope.

A rating envelope is a written specification of the most intense content the game can produce in each category, enforced in code:

• Characters are instructed and fine-tuned to stay within it.
• An output classifier checks every generated line against the envelope's categories before the player sees it.
• Lines that fail are replaced with an authored fallback, not just blocked, so the experience doesn't stall.
• Evaluation suites run thousands of adversarial conversations against the envelope on every build.

Your rating is then based on the envelope, and your documentation shows how it's enforced. Some online-interaction notices may still apply where players can interact with each other or with unmoderated content.

Writing a disclosure players trust

Many studios write AI disclosures defensively: short, vague, buried. Players notice, and assume the worst. Disclosures that are specific tend to land better. Compare:

Specific disclosures do three things: they show where human craft is, they explain why AI is there, and they tell players what to do if something goes wrong.

Player input and privacy

Games with free-text or voice input collect something most games never have: whatever players choose to type or say. Some of it will be personal. Treat it that way from the start:

• Minimise retention. Keep raw player input only as long as you need it for the game and for safety review. Store memories as summaries, not transcripts, where you can.
• Be clear about training. If you want to use player conversations to improve models, say so plainly, make it opt-in where required, and strip identifying details first.
• Check your providers. If you send input to a third-party model API, know its retention and training policies and make sure your privacy policy reflects them.
• Handle voice carefully. Voice recordings can be biometric data in some jurisdictions. Transcribe on-device where possible and discard the audio.
• Think about younger players. If your audience may include children, the rules on collecting their data are much stricter in many countries. Design for it, don't retrofit.

None of this is legal advice; privacy law varies by country and changes often. Get a specialist review before launch, and keep your data-handling section of the AI documentation in sync with what the game actually does.

Pre-launch checklist

The list we run for every AI-native title in the last month before release:

• AI-use inventory complete, covering every model, where it runs, and pre-generated vs live.
• Store-page disclosure written in plain language and reviewed by the narrative lead.
• Rating envelope documented, enforced by classifier, with authored fallbacks for every category.
• Full eval suite passing on the release build, including adversarial conversations.
• In-game reporting for generated content working and routed to a reviewed queue.
• Server-side guardrail updates tested end to end without a client patch.
• Privacy policy matches actual retention and training behaviour.
• Offline and degraded-mode behaviour tested on every platform.
• A named owner for AI incidents during launch week, with an escalation path.

After launch: monitoring and updates

Players will find edges your testing didn't. Plan for it:

• Sample and review generated output continuously, with automated classifiers and human reviewers looking at a random sample plus everything flagged.
• Watch for drift when you change models or prompts. Re-run your full eval suite before every change reaches players.
• Ship guardrail updates server-side so you can respond in hours, not wait for platform certification of a client patch.
• Keep your disclosures current. If you add a new AI system in an update, update the store page.

At Ammighty, this monitoring is part of live-ops for every title we publish, and our production team builds the rating envelope and eval suite during development.

Frequently asked questions

Related

• Content safety and evaluation services
• What is an AI-native game?
• LLM NPC inference costs