AI in a cautious studio

Studios tend to arrive at one of two untidy positions on AI.

In the first, it has been banned and a few people quietly use consumer accounts anyway. In the second, it has been permitted, but nobody can say which tools are being used, what was uploaded or whether any output reached the game.

The second sounds more progressive. From a diligence or publisher point of view it can be worse, because the studio has accepted the exposure without keeping the evidence needed to explain it.

I favour a fairly cautious policy, but a real one: short enough to read, practical enough to follow, and willing to distinguish low-drama internal work from material which ships to players.

The useful work is often beside the game

The least controversial uses are frequently in the pipeline rather than the product. Build-log triage, first drafts of tests, checking localisation consistency, grouping telemetry, reviewing repetitive data and making small internal tools can all be reasonable experiments.

These jobs share a useful property: a person can check the output against evidence, and a bad answer need not become part of the shipped creative work. The tool assists an existing process rather than becoming the authority for it.

Code completion can sit in a similar category if engineers review what enters the repository and the tool is approved for the material it sees. “The developer looked at it” is not magical protection, but it is much better than automatically accepting generated changes because the tests happened to pass.

I would begin with a small number of such cases, not a studio-wide instruction to “use AI”. The latter produces activity. It does not tell anybody whether the work improved.

Confidentiality comes first

A developer pasting an unreleased crash log or a section of proprietary code into a public consumer service may have shared far more than intended. The exact treatment depends on the provider, product tier and current terms, so “it’s ChatGPT” or “it’s enterprise” is not enough information.

Approve specific tools and account types. Record what classes of material may be used with each. For sensitive projects, an enterprise agreement or locally controlled model may be appropriate; sometimes the correct answer is simply that the material stays out.

This should align with publisher, platform and client obligations. An internal policy cannot grant permission a contract has already withheld.

Ownership is partly a record-keeping problem

Arguments about generative output tend to become abstract very quickly. A studio has a more immediate operational question: can it identify where material came from, who reviewed it and what representations it later makes to a publisher, platform holder or buyer?

Separate generated material which may ship from transient help during internal work. Keep records proportionate to the risk. A suggested test name does not need the same process as a character design, localisation file or large code submission.

Vendors and outsourcers belong in the policy too. Asking the internal team to keep provenance records while accepting unqualified deliveries from a supplier leaves a fairly obvious hole.

A one-page policy is usually enough to start

I would expect the first version to answer six things:

1. Material classes: what is public, internal, confidential or restricted?
2. Approved tools: which product and account type may be used for each class?
3. Review: who is responsible for checking output before it enters a repository, asset system or decision?
4. Records: what use must be noted, and where?
5. Prohibitions: what must not be uploaded or generated?
6. Edge cases: who can make a prompt decision when the policy does not cover something?

Use examples. “Do not disclose confidential information” is correct and not terribly helpful at 11pm when somebody is deciding whether a call stack is confidential. Name source code, crash dumps, player data, unannounced designs, partner documentation and personal data as appropriate.

The policy will change. Tools and terms change, and the studio will learn which experiments are useful. Give it an owner and a review date rather than pretending the first page is constitutional law.

Measure the work, not the feeling

AI tools often feel quick because they produce something immediately. That is not the same as shortening the completed task.

For an experiment, measure cycle time to an accepted result, defects found later and downstream review effort. If an engineer creates a utility in half the time but two colleagues spend longer verifying and repairing it, the team has moved the work rather than removed it.

Run the comparison on a few real tasks. Self-reported hours saved are a weak measure; people are understandably impressed by the first draft appearing in seconds. The editing after the first draft is where the claim either survives or quietly dies.

Some uses will be worthwhile and others will not. That is a healthier conclusion than requiring the whole studio to share one enthusiasm level.

Where I would be deliberately slow

I would avoid generative material in the shipped product unless there is a specific creative or production reason, a known tool and rights position, proper records, and agreement from the relevant partners. “We wanted to see if it was faster” is not much compensation for uncertainty in a central asset pipeline.

I would not restructure a team around vendor claims or a short pilot. Nor would I use the tools in ways the studio would feel uncomfortable explaining plainly to its artists, developers or customers. If the internal announcement requires careful euphemism, the policy probably needs another look.

A deliberate no-use position can also be valid, particularly where contracts, material sensitivity or the nature of the creative work make the benefits small. It should still be explicit and enforced with approved alternatives, rather than a sign on the door while shadow use continues.

The aim is not to look early or late. It is to know what the studio is doing, why it is doing it, and whether the promised saving survives the whole workflow.