Same System, Different Scale: What Stays Constant When AI Spreads Across a Firm, and the 2 Decisions Growth Adds

What Changes When One Team's AI System Becomes the Firm's?

Less than the instinct suggests. The people, the ownership and the measure that made the first system work should travel with it unchanged.

What changes is that 2 questions which one team could settle over a desk now need an answer the whole firm can read: who may change the shared system, and who may see across it.

The rebuild instinct is understandable. Growth feels like a different kind of problem, so it seems to call for a different kind of solution: a dedicated team, a platform decision, a programme with phases.

Each of those can have its place, but none of them is the starting point. The starting point is to ask what the first system proved, and to protect it.

What it proved, if it earned its scale-up properly, is specific. The people closest to the work could shape it, a named person stood behind every result, and the firm could say which work it improved.

Those are the 3 constants. A rebuild that hands the building to someone else, blurs the ownership or switches to counting seats has quietly replaced the thing that worked with something that has not yet been tested.

In the operating-model framework I use, this is the point where each of the 3 verbs changes character.

Codifying the firm's judgement becomes institutional memory under change control, and governing becomes formal decision rights, risk boundaries and oversight. What follows is what those 2 shifts look like when a firm actually makes them.

A word about the sources

The external examples in this article come from 4 pages published by 1 organisation, OpenAI: Sarah Friar describing the finance team she leads there, 2 product announcements and a guide to its own analytics.

None of them is independent research. Each is a company describing itself, with a commercial interest in the products it mentions.

So what matters is the pattern, not anybody's account of their own results. Every pattern here can be tested against your own firm without believing a word of what one vendor says about itself.

Nothing here is a recommendation to buy them. The one example from my own system is labelled as such.

What Should Stay Constant as an AI System Grows?

3 things: who builds, who owns the result, and how value is judged. Each is under pressure as a system spreads, and each is worth defending on purpose, because each drifts quietly rather than breaking loudly.

1. The people closest to the work keep building

Growth tempts a firm to hand the building work to a central team, which takes requests and ships tools. That quietly separates what gets built from the expertise it was meant to carry, and it can turn improvements into requests waiting in a queue.

The better pattern, in my view, keeps the building with the experts and moves the specialists into support.

Sarah Friar, describing the finance team she leads at OpenAI, in August 2026, puts the reason plainly: her team is not becoming less specialised, it is gaining the ability to carry its expertise further.

She describes bringing sales engineers into a finance hackathon and asking the team to bring work they wanted to change, and she is clear about where the ideas came from: "The use cases came from the people closest to the work, while technical experts helped them move faster."

One of her examples is a teammate on the advertising side who had never written code and built a tool that turns the monthly advertising forecast into weekly and daily plans, with every number tied to the approved model.

The detail worth noticing is the last one. The person who understood the forecast built the tool, and the tool stayed attached to the figures the firm had already approved.

For an expert firm, the translation is direct. The partner who knows how a review should go is the right person to shape the routine that prepares it. A central team can make that person faster. It cannot replace what that person knows.

2. A named person owns every result

More users produce more output, and the easy drift is towards output that nobody in particular owns. Friar's line is the right one to keep: "AI accelerates the work. People own the result."

The principle I would hold to at every scale is simple: the person whose name sits on a result should be the person who would have owned it without the system.

If a senior associate would have signed the memo before, the senior associate signs it now. The system changes how the work is prepared, not who answers for it.

Growth makes that harder to see, because a result can pass through several people and several steps before it leaves the firm.

Name the owner before it does. A result that reaches a client with 3 contributors and no owner is not a shared success. It is an unowned risk.

3. Value is judged per workflow, not per seat

A system that spreads produces easy numbers to report: licences issued, people active, volume used. None of them says whether work that mattered got done.

Friar is blunt that buying more seats or using more tokens tells a firm little.

Among the 4 questions she asks of each workflow are "Did AI complete work that mattered?" and "Was the result good enough to use?", and she counts the cost of review and rework alongside the rest.

OpenAI's own guide to its usage analytics, published in September 2026, makes the same point about its own dashboards: "Usage and task data are a starting point for admins to investigate value with business owners."

Activity tells you where to look. It does not tell you what the looking will find.

Keep the per-workflow measure as the system grows. It is the measure that lets 2 teams, or 2 parts of a group, be compared honestly, and it is the one I set out in detail in what to measure before you claim a return.

As It Becomes a Leadership Team's: Who May Change the Shared System?

Someone named, through a route everyone can see. When a team's way of working becomes a leadership team's, the instructions behind the system stop being one person's working notes.

What the system is told to do, to check and to avoid becomes shared infrastructure, as much as any policy the whole firm relies on.

At this scale, change needs as much care as quality. Several people, and sometimes the system itself, can alter the shared instructions. Without a record, it is harder to establish afterwards what changed, when, or why, and much harder to put it back.

So the leadership team's new decision is who may change the shared system, and how a change is proposed, recorded and read. It is the same change control a firm already applies to its policies, extended to the instructions its AI works from.

Friar applies the same idea to her own numbers: she writes that every change to an approved baseline should require authorisation from finance. In my view, the instructions a firm's AI works from deserve the same treatment as its approved figures.

OpenAI's analytics guide makes a narrower point that leans the same way, noting that "a frequently used skill may need a clear owner and regular updates". It says nothing about approvals or records. The step from an owner to change control is mine.

What change control looks like in practice

In practice it comes down to 3 things:

• A named owner for the shared instructions, who decides what goes in.
• A place where a proposed change waits until that owner accepts it, so a good idea from one team does not silently become everyone's rule.
• A record of what changed and why, readable by everyone who relies on the system.

The record is the part most worth getting right, and it does not need to be elaborate.

Each entry answers 6 questions: what changed, in which instruction; when; who proposed it; who accepted it; why; and where the previous version is kept, so the change can be undone.

None of the 3 is technical. A firm that already controls changes to its own policies knows how to run all of them. The new part is recognising that the instructions behind its AI are now one of those policies.

An example from my own system

This is the one example in the article that comes from my own work, and it is why I take the question seriously.

An hourly monitoring agent in my own system was once allowed to add its lessons to its own instruction file.

It took that file from 313 lines to 2,020 in under 3 weeks. None of the growth was new ability: every script the rebuilt instructions call was already in the 313-line version.

Its instructions were rebuilt at 100 lines. The rule it works under today is that it may not add to its own instructions.

It may correct a fact in them that has stopped being true, such as a path that has moved, but only after copying the file first. What it learns is written to a separate log instead, one line per lesson.

That is change control at the scale of one agent: a boundary on what may change, a copy kept before anything does, and a separate place for what is learned.

For a leadership team I would go one step further: a named person decides which lessons become shared rules, and that name belongs in writing.

I do not offer this as a solved problem. I offer it because it is a measured case of what can happen when instructions can be added to and nobody has to accept the additions.

One agent is not a team, and I would not read more into it than that.

But my concern for a leadership team is the same: shared instructions that many people can add to, with no owner accepting the changes, could drift in the same direction.

As It Becomes a Group's: Who May See Across the Walls?

As few people as the work requires, and the walls are settings in the system. A group adds something new to design for: parts that must not see each other's material.

The way of working can be shared across the group. The client files, commercial terms and personnel records behind it are not shared by default.

So the group's new decision is who may see across the walls, and the design move is to make the walls part of the system rather than a promise that people will be careful.

Where a firm already keeps some of its people apart from each other's work, the question growth asks is whether the AI system honours the same walls the people already work behind.

What a wall looks like when it is a setting

OpenAI's product for financial institutions, announced in September 2026, describes a version of that move: "Multiple workspaces can also be created to enforce information barriers."

On the same page, access to skills and apps can be managed by role, supported app read and write actions can be enabled or disabled, and compliance teams can export supported workspace logs into their existing audit and investigation work.

It is available to eligible financial institutions, and the product is not the point. The point is that the wall is a setting someone chose, not a habit someone hopes for. A setting can be checked, recorded and audited. A habit can only be trusted.

The same publisher has since said, in its September 2026 announcement for legal work, that it is working with a law firm "to design for information permissions, ethical walls, client instructions, and firm oversight".

That is a design collaboration announced, not a feature shipped, and I cite it only for what it shows: the walls are now a design question for the vendors too.

If your firm is regulated in the UK, I have set the published positions of 4 professional and regulatory bodies side by side in a separate article. The walls described here sit naturally alongside duties a regulated firm already carries.

One list of controls, local owners

The rest of the group's design is one set of controls with local owners. Friar's essay names the set well.

The controls to define are "which data an AI system can access, which actions it can take, when approval is required, and when an issue should be escalated."

The group decides that list once, and each part of the group owns its own answers. Split that way, the work divides cleanly:

• Decided once, by the group: that every part answers the same 4 controls; where the answers are written down; that the walls between parts are settings rather than promises; and how a change to any answer is recorded.
• Answered locally, by each part: which of its own data the system may use; which actions it may take there; where a person approves before anything happens; and who is told when something looks wrong.

A team whose work goes straight to clients may want approval earlier than one drafting internal analysis, and both answers belong to the people accountable for that work.

A single answer for everyone may fit some parts of a group and not others, and the people accountable for each part are best placed to say which. The shared list is what lets the centre see, in one format, how each part has answered.

The person at the centre

Somebody at the centre of the group does need to see across the walls, to notice what works in one part and bring it to another.

What that role needs to see is the way of working and the results against the measure, not the material behind them.

That person sees the method and the measures from every part of the group. No role, including theirs, opens another part's material by default. That is how a group can share what it learns without sharing what it holds.

It also explains why the per-workflow measure matters so much at this scale. It is the comparison that says which work improved, and the centre can make it across the walls without crossing them.

Seats and usage can be compared too, but, as above, they do not say which work improved.

When Should a Firm Take These 2 Decisions?

While the system is still small, before access spreads. At that point, in my judgement, agreeing them takes a conversation rather than a negotiation, because fewer people depend on the system yet.

The timing matters for a human reason, not a technical one. Once everyone already has access, a new restriction tends to read as something being taken away.

The same rule that would have been an obvious starting condition becomes, a few months later, a change people have to be persuaded to accept.

That is also why neither decision has to be heavy. The firm's existing habits of writing down what goes where and who owns it are enough to start. The 2 decisions add a few lines to that page, not a new department.

And it is why both decisions sit comfortably with the earlier tests of a first system.

If the team can already run it without the person who built it, then the instructions are already partly shared, and deciding who may change them is simply making that sharing deliberate.

The Verdict

A way of working that scales well is not rebuilt at every size. It keeps its builders, its owners and its measure, and it adds 2 decisions: who may change it, and who may see across it.

The easiest time to write the rules about change and visibility is before everyone depends on the system.

This is the work I do, and I run my own practice on the same kind of system. If your firm is about to take one team's way of working to the rest of the business, see how the engagements work and send a note.

I am happy to talk through where those 2 decisions should sit. The thinking continues in The AI Operating System, my fortnightly LinkedIn newsletter, where an earlier version of this argument first appeared.

Frequently Asked Questions

Do we need a central AI team to scale AI across the firm?

Not as the owner of the building work. A central group can be valuable in support: setting the shared list of controls, keeping the record of changes and helping teams move faster.

In my view, the building itself is best left with the people closest to the work, because that is where the expertise the system carries comes from.

Should an AI system be allowed to update its own instructions?

Not to add to them without a person deciding. In my own system, an agent may correct a fact that has stopped being true, after keeping a copy, and writes what it learns to a separate log.

For shared instructions a leadership team relies on, I would add a named person who decides which lessons become rules.

What is an information barrier in an AI system?

A wall between parts of a firm or group that the system itself enforces, such as separate workspaces with their own access, rather than an instruction asking people to be careful.

The useful test is whether the wall can be checked and audited. If it can only be trusted, it is a habit, not a setting.

Who should own the shared instructions?

A named person with authority over the work those instructions govern, not whoever happens to be most enthusiastic about the tool.

The owner accepts or declines proposed changes and keeps the record readable. In a group, each part owns its own answers to the shared list of controls.

How should we compare AI value across teams?

Per workflow, against the same questions everywhere: did it complete work that mattered, was the result good enough to use, and what did it cost once review and rework are counted.

Seats, active users and volume are useful for finding where to look. They are not the comparison itself.

Sources

Each page was read at the publisher's own site on 20 October 2026. Each is an organisation describing its own team or products.

• Sarah Friar, OpenAI, What building an AI-native finance function taught me, 10 August 2026.
• OpenAI, Introducing ChatGPT for Financial Services, 10 September 2026.
• OpenAI, How to connect AI usage to business value, 16 September 2026.
• OpenAI, Introducing Astra for Law, 17 September 2026.

Dr Bruno Oliveira — PhD · Associate Professor, University of Bath. Founder of GustoMind.ai. Builds and installs AI operating systems for expert-led firms, running the same system daily in his own work.