Why studio AI should be local-first

A studio is preparing an unreleased campaign. Camera originals and interview recordings sit on its storage. Internal cuts are moving through review. Client feedback appears beside versions, while production documents and team conversations contain the decisions behind them.

An AI assistant could find a spoken line, a visually similar shot or an approved version. But before asking what the model can do, the studio should ask:

The answer may involve an external service. Data movement should be a deliberate architectural decision, not an invisible consequence of choosing a feature.

For a media studio, privacy starts there.

Creative media is not ordinary business data

Production systems hold an unusual combination of material. There are large original files, lightweight proxies, internal versions, interview recordings, schedules, contracts, review comments and everyday conversations. Some material will be published eventually. Some may never be. Rights and access can differ by project, client, contributor, territory and stage of production.

The archive also has a long memory. A document may be useful for a month; a shot may become valuable again years after delivery. Over that period, the studio creates more derived material: thumbnails, previews, transcripts, metadata, review histories and search indexes.

This does not make production data uniquely dangerous. Its handling is already part of professional production judgement: studios control who receives camera originals, which cuts a freelancer can open and where client feedback is stored. An AI system should fit that discipline rather than ask the studio to suspend it.

Scale matters too. Moving a working archive to another system can be slow, costly or simply unnecessary. When the source already lives on studio storage, processing it close to that storage can be both a privacy decision and a practical one.

Cloud-first is an architectural choice

Many AI products follow a straightforward pattern: content is sent to a hosted service, processed there and returned as a result. This model can offer rapid deployment, managed infrastructure, elastic capacity and simpler updates. Cloud providers can also offer substantial security controls. “Cloud” is not a synonym for “unsafe”.

It is, however, a choice about data flow.

The relevant questions are specific. Is a full media file uploaded, or a transcript fragment? Is the content retained after processing? Does the service store queries and answers? Where is an index held? Which other systems can the service reach? Can different projects have different boundaries?

If those questions have not been answered, a privacy statement alone tells the studio very little about the real deployment.

That operational convenience may be entirely reasonable for some sources and workflows. It should not silently determine how unreleased media, internal comments or a long-lived archive are handled.

What local-first actually means

Local-first is an architectural preference that keeps sensitive, heavy or operationally important processing close to the studio’s existing systems.

In a studio deployment, that can mean originals remain on the storage already responsible for them. Supported media is processed close to that storage. Thumbnails and previews are generated locally. Eligible media is transcribed locally. Searchable representations and indexes can also be created within an environment controlled for that studio.

These smaller representations allow the system to search and inspect supported material without treating every question as a reason to move a full-resolution original. Existing storage and access arrangements continue to govern the source.

Local-first begins with the studio’s infrastructure rather than an assumed migration. A facility should not have to replace its shared storage, MAM or DAM, review platform and project tracker before the combined context across those systems becomes useful. The intelligence layer works across them within agreed access boundaries.

This is the approach behind Foma: Local-first and privately deployed. Media processing stays on-site. Supported media can receive locally generated thumbnails and previews, and eligible media can be transcribed locally. The exact boundary of a deployment still has to be agreed with the individual studio.

In a hybrid Foma deployment, media analysis and locally generated derivatives can remain within the studio-controlled environment while selected text context is sent to a studio-approved external model. The exact content, retention and provider boundary must be agreed with each studio.

Local-first is not local-only

Several terms are often compressed into the word “private”, although they describe different properties.

A cloud-hosted system runs in infrastructure operated outside the studio. For Foma, privately deployed means single-tenant: provisioned for one studio rather than offered as a shared public workspace. Depending on the deployment, that environment may be on-site, hosted or divided between both. A local-first system gives priority to local data and processing, especially where moving the source is unnecessary or undesirable.

A hybrid deployment combines local and external components. A fully local deployment keeps the defined system components within the studio-controlled environment. An air-gapped deployment is additionally isolated from external networks. These are not interchangeable descriptions.

A local-first architecture may be hybrid. For example, media analysis may occur on-site while a limited, approved piece of text is handled elsewhere. Another studio may require more components to remain inside its own environment. A particular project may need tighter controls than the studio’s general work.

The label matters less than a documented answer for each type of data. Where does it go? What processes it? What is retained? Who can retrieve it? A system can call itself private while leaving those boundaries unclear. Conversely, a carefully designed hybrid deployment can provide meaningful control because its boundaries are explicit.

Foma should therefore not be assumed to be fully local, offline or air-gapped unless those boundaries are confirmed for a particular deployment.

Follow the data, not the marketing language

The clearest way to assess studio AI is to draw the route from source to answer.

Start with originals. Where do they live, and does the system read them in place or copy them elsewhere? Then follow every processing step. Where are previews created? Where does transcription run? What exactly is passed to a model: raw media, a frame, a transcript, selected metadata or a limited bundle of context?

Continue beyond processing. Where is the search index stored? Are prompts and answers retained, and for how long? Which connected systems can the assistant inspect? Does a person inherit the permissions they already have, or does the assistant expose a broader view? Can a source be disabled, re-indexed or removed? What happens to its derived data afterwards?

Finally, follow the answer back. Can the user open the file, timestamp, document, review comment or task that supports it? If two sources conflict, does the system reveal the disagreement?

This exercise turns an abstract assurance into an operational map. It also makes comparison easier. Two products may offer a similar conversational interface while moving and retaining very different material behind it.

Derived assets matter too

Protecting originals is only part of the picture. A small derivative can still reveal a great deal.

A thumbnail may show an unreleased product. A transcript can contain a contributor’s personal account. Filenames and storage paths may reveal client names or campaign structure. Review comments record opinions and decisions. User queries can reveal what the studio is investigating. Generated answers can assemble sensitive context from several otherwise separate sources.

Searchable representations deserve the same attention. Some systems create embeddings: mathematical representations that help compare meaning or visual similarity. They are not simply copies of the source, but neither should they be treated as content-free. Their location, permissions, retention and deletion should be part of the design.

The practical question is therefore wider than “Are the originals local?” It is “What knowledge can each derived asset reveal, and how is that asset governed?”

Read-only by design

An assistant that can see across storage, review, project tracking, documents and conversations has a broad view of the studio. That does not mean it also needs authority to change those systems.

Read-only access separates understanding from action. A search should not rename a clip, move a folder, close a task or change an approval. The system can help a producer locate the current decision without becoming another place where that decision is made.

This reduces the risk of accidental changes and makes an initial deployment easier to reason about. It also gives the team a clearer mental model: the assistant can inspect accessible evidence, but the existing production systems remain authoritative.

Read-only is not a complete security strategy. The assistant still needs appropriate identity, permissions, logging and isolation. A read operation can expose information to the wrong person if access is too broad. Least privilege still matters: the system should receive only the access required for the agreed questions and sources.

If a studio later wants automated actions, those can be considered separately, with narrower permissions, visible confirmation and their own operational safeguards. Search and understanding do not need to inherit that risk on day one.

Provenance instead of blind trust

Where processing happens and how an answer is presented are connected questions. Keeping media local does not make an answer correct.

A useful answer should show its provenance: the source system, project, file or document, and the relevant timestamp, transcript fragment, review comment, path or other available reference. The user should be able to move from summary to evidence without beginning the investigation again.

Provenance supports production judgement. An editor can play the located moment. A producer can confirm that an approval belongs to the current version. If sources disagree, the system can expose the disagreement instead of inventing certainty.

This is why Private Studio Intelligence is more than a private chat interface. Privacy shapes where the work is processed; provenance makes the result accountable to the work itself.

The practical trade-offs

Local-first deployment exchanges some operational simplicity for greater control. That is a real trade, not a free improvement.

Processing near the archive may require studio-owned or managed hardware. Initial and ongoing indexing should be scheduled and rate-limited so that it does not compete with grading, conform or delivery for storage bandwidth. Storage is required for previews, transcripts and indexes. Someone must monitor services, manage updates and review access policies.

Performance and capabilities can vary with the available infrastructure. A managed external service may release improvements more quickly or absorb peaks more easily. A local component must be sized, maintained and observed.

Nor does local-first make a system automatically private or secure. Weak permissions, indefinite retention or an exposed interface remain problems wherever the hardware sits. Physical location is one layer of control; identity, access, operations and clear data lifecycles are others.

The benefit is not the disappearance of responsibility. It is the ability to make more of those decisions deliberately: which processing stays near the archive, which components may be external and what evidence exists for each answer.

When local-first makes sense

Local-first is particularly worth considering when a studio handles unreleased material, maintains a substantial archive or already operates production storage. It is useful when originals cannot be sent indiscriminately to external services, processing should happen near the source, or permissions and retention vary across projects.

It can also suit a gradual introduction of AI. The studio can begin with defined sources, read-only access and a small set of valuable questions. It can observe the data flow and operational load before expanding coverage.

Another organisation may prefer a managed cloud service for less sensitive material, or choose a hybrid architecture because it balances control with operational capacity. Local-first is not the only responsible model. Its value is that it makes the studio’s existing obligations and infrastructure the starting point rather than an exception.

A practical evaluation checklist

When speaking with an AI provider or designing an internal system, a studio’s Technical Director, Head of Post or MD should be able to obtain clear answers to the following:

Data location

• Where do originals, documents, indexes, queries and answers reside?
• Can location and boundaries differ by source or project?

Media processing

• Where are previews, thumbnails and transcripts created?
• Is full media transferred, or is processing performed close to storage?
• How are unsupported or failed files handled?

Model access

• What exact content is passed to each model or service?
• Can external processing be disabled for selected sources?

Storage and retention

• Are prompts, answers and derived assets retained, and for how long?
• Does deleting a source also remove its transcript, previews and searchable representations?

Permissions

• Does the assistant respect existing user and project access?
• Is access read-only, and what would require additional authority?

Provenance

• Can every answer lead back to inspectable evidence?
• How are uncertainty, conflicting sources and transcription errors shown?

Operations

• Who maintains the deployment, applies updates and monitors failures?
• What capacity is required for initial indexing and ongoing work?

Exit and deletion

• Can the studio export or remove its indexes and derived assets?
• What is the verified deletion process when a source, project or deployment is retired?

These questions are useful even when the final architecture is cloud-hosted. Their purpose is not to steer every studio towards the same topology. It is to replace vague assurances with an understandable operating model.

These are also the questions that should define every Foma deployment. The answers may differ between studios, but the boundaries should be explicit before production material is connected.

Private intelligence begins with architecture

Privacy cannot be added at the end as a preference in a settings screen. Decisions about data location, media processing, permissions, retention and provenance have to be part of the system’s first design.

For Foma, that principle is expressed as Local-first and privately deployed. Media processing stays on-site. The specific deployment boundary must still reflect the infrastructure, policies and project requirements of each studio. Local-first does not mean pretending every environment is identical. It means beginning with control of the studio’s material and documenting every justified exception.

The most useful first conversation is therefore not about choosing a model. It is about mapping the work: where media and project knowledge live, which questions the team needs to answer, what can be processed locally, what may be passed to an external component and which sources must remain read-only.

Once that map exists, the studio can evaluate AI on practical terms. It can ask not only what the system knows, but how it came to know it — and what had to leave the studio along the way.