Generative AI operations in a game studio, where review came before adoption

Work appeared between the tool opened daily and the output nobody ships

The preview edition of the CESA Games White Paper 2026, published by the Computer Entertainment Supplier’s Association on 17 September 2026, carries a developer survey and a member-company survey together for the first time. In the developer survey, 85.8% of respondents said they use generative AI in their work; inside that, 63.0% use it routinely and 22.8% occasionally. Another 8.6% are trialling it for evaluation, 4.8% have never used it and 0.7% used to but no longer do.

In the same report’s member-company survey, the answer that drew the most responses on managing generative AI use was that a person checks, corrects and reviews the output. One side described what happens at the desk; the other described what company policy allows. Where both answers hold, drafting time shrinks and the time spent going back over what was drafted grows.

Whose job that growing half is describes this specialization. The tool 63.0% of developers open every day is not the last tool before a finished product; it is a tool that produces drafts mid-process. Someone has to put rules between the draft and the finished product, and make those rules run inside the actual build pipeline.

The rules land at the entrance, in the middle and at the exit

Member companies did not pick one measure. Alongside the review answer, many also responded that they designate or restrict which tools may be used, and that they do not ship model output as-is. The three answers point at three different moments in the work. Designating tools narrows the entrance, the no-raw-output principle operates mid-process, and human review is the last gate.

Each of the three demands a different skill. The entrance is about accounts and permissions: which tools are opened inside the network, and by what route work produced outside comes back in. The middle is about deliverables. Someone decides how far the no-raw-output rule reaches across textures, sound, dialogue and code, then designs the markings that make that boundary visible in version control. The exit is about people: who reviews at which stage, what line cannot be crossed, and where anything that fails the gate goes back to.

Controlling all three at once is a signal that these companies treat adoption and trust as separate decisions. They have settled on using it; they have not settled on believing what comes out, and filling that gap is the scope of this role.

Where success is measured in efficiency, review time becomes a cost

Asked what they expect most from generative AI, member companies named efficiency and higher productivity. Not making something new, and not doing what people could not do before, but finishing existing work faster. When the goal sits there, the yardstick follows. Instead of what is new, the measure becomes how many days the same volume took.

On that yardstick, review time is a cost line. Tighter rules are safer but eat into the benefit; looser rules widen the benefit but leave more to catch at the exit. What this role actually measures is not model quality but the point between those two. Counting how much the rework rate fell once review was attached to a given deliverable, and how many things slipped through where review was skipped, takes up half the job.

The same is true of changing the rules: you need the numbers first. A rule here is less a document settled once than a setting applied differently per stage. Some stages need one look at the end; others need a line mid-process that nothing crosses.

The shortest way in runs through the pipeline

The report does not say who inside a company takes this on. But because all three measures are rules laid over the production pipeline, anyone who does not know the pipeline cannot decide where the checkpoints go. Someone who already knows the build order, when art and sound are merged, and where review stalls has the shortest path into the rules side.

The reverse path exists too: coming into game production from governance or compliance work. What has to be filled in first there is the taxonomy of deliverables. A block of text and a single texture differ in review cost and in the cost of undoing them. Miss that difference and every deliverable gets the same rule, and rules like that are not followed on the floor.

Growth runs along the same two axes. First a rule is attached to one stage and tried; then a review flow spanning several stages is designed; then outsourcing and contract terms are brought under the same standard. At the last step the documents look less like code and more like contracts.

The first thing this role produces is a single sheet

What gets made first is usually one table: which stage uses what, where the result flows, who reviews at which point, and what line cannot be crossed, all on one page. Without it, review differs person to person, and that difference only surfaces just before release.

Because this is the first time CESA has surveyed game developers directly, there is no figure from last year to set beside it. Whether 85.8% is a rise or a fall waits on the next survey, and the preview announcement does not say which stage of production the check-correct-review answer refers to. Filling that blank company by company is what sits with this role now.