For many organisations, the biggest obstacle to using generative AI has not been lack of interest. It has been confidentiality. Boards, executives, legal teams, company secretaries, risk teams and compliance functions can see the productivity opportunity, but they are rightly cautious about putting board papers, contracts, investigations, source code, customer information, regulatory correspondence or privileged material into tools they do not control.

That caution is not old-fashioned. It is good governance. Consumer AI tools are not designed for unrestricted use with sensitive corporate information. Enterprise cloud tools may offer stronger contractual, security and administrative controls, but they still require close attention to data flows, retention settings, vendor terms, access management and assurance. For some organisations, that has meant using AI only at the margins - or not using it at all for work that would otherwise benefit most from analytical assistance.

Local AI models may change that conversation.

A local AI model is, in broad terms, an AI model that performs its work on infrastructure controlled by the organisation, rather than by sending every prompt and output to a third-party public service. That infrastructure might be a director’s approved device, a secured internal workstation, an on-premise server, a private cloud environment or, for the most sensitive use cases, an air-gapped environment with no external connectivity. The model might be used alone, or connected to an internal document repository through retrieval-augmented generation so that users can ask questions of approved internal material.

Properly configured, this can be powerful. It may allow an organisation to use AI on classes of information that would otherwise be off-limits. It may reduce exposure to third-party data processing. It may support offline or highly restricted environments. It may give the organisation more control over logs, model versions, access rights and retention. It may also provide resilience if access to a third-party model changes, degrades or is withdrawn.

But local AI is not a magic box. It is not automatically safe because it is local. It is not automatically accurate because it is private. It is not automatically lawful because data does not cross an external API. From a governance perspective, local AI should be treated as a new capability that may expand the permitted use of AI - not as a shortcut around existing duties, controls or assurance.

What has changed?

Three developments have made local AI more plausible for ordinary organisations.

First, the quality of open-weight models has improved. Open-weight does not necessarily mean open-source in the strict sense. It generally means that the trained model weights can be downloaded and run by others, subject to the applicable licence and use restrictions. The important practical point is that organisations are no longer limited to cloud-only access for every useful AI capability.

Second, the software stack has become easier to use. Local AI runtimes and interfaces have made it more realistic for technical teams to test, run and manage models on controlled infrastructure. That does not remove the need for expertise, but it lowers the barrier to experimentation.

Third, hardware has improved. Modern workstations, servers and unified-memory devices can run increasingly capable models locally. Performance will still depend on model size, quantisation, memory, bandwidth, concurrency and workload. A local deployment may be slower or less capable than a frontier cloud model. Even so, the practical range of useful local use cases has expanded significantly.

The result is not that cloud AI becomes redundant. It is that organisations may be able to use different kinds of AI for different kinds of work.

A three-tier AI operating model

A sensible governance response is not to ask whether the organisation should use AI or not. The better question is: which AI, for which data, under which controls?

Model tier

Likely use

Core governance rule

Consumer or public AI

Public information, general learning, non-confidential drafting prompts and low-risk experimentation.

No confidential, personal, privileged, client, board, security, source-code or regulated information.

Enterprise cloud AI

Approved internal productivity use, drafting, summarisation, coding assistance, workflow support and non-sensitive analysis where enterprise controls are adequate.

Use only through approved accounts, settings, contractual protections, access controls and data-handling rules.

Local or on-premise AI

Board and committee work, sensitive internal analysis, regulated data, privileged or pre-decisional material, internal knowledge search and approved high-confidentiality use cases.

Use only in approved environments, with clear ownership, monitoring, validation, records controls and legal hold processes.

This tiered model aligns AI use with information classification. It allows the organisation to be pragmatic without being casual. A company secretary might use an approved enterprise tool to draft a non-confidential training outline, while a board portal-related analysis of confidential board papers may be reserved for an approved local environment. A staff member asking a generic question about meeting etiquette might use a public tool, while no one should paste a draft market announcement, board paper or customer file into one.

Why boards and company secretaries should be interested

Local AI models are particularly relevant to board and governance work because the information involved is often highly sensitive. Board packs may contain strategy, capital management, M&A, regulatory matters, litigation, executive remuneration, cyber incidents, prudential issues and market-sensitive information. Committee papers may include internal audit findings, whistleblower matters, investigation reports, customer remediation, risk registers and draft disclosures.

These are exactly the kinds of materials that could benefit from careful AI-enabled support - summarisation, issue mapping, consistency checks, comparison against charters or policies, question generation, obligation mapping and document navigation. They are also exactly the kinds of materials that should not be placed into unsuitable AI tools.

A well-controlled local AI environment could support several governance use cases:

preparing first-pass summaries of lengthy internal papers, with human review before circulation;

helping directors and executives identify questions to ask management;

mapping draft board papers against board-approved templates, charters, delegations and workplans;

searching an internal governance library for relevant policies, resolutions, precedents and registers;

assisting with first drafts of minutes or action lists from approved source materials, subject to rigorous human review;

comparing policies, charters or governance documents for internal consistency; and

supporting due diligence, compliance or assurance work where the data set is sensitive.

The common feature is not automation for its own sake. It is controlled augmentation. Local AI should assist responsible officers and directors to do their work better, not replace judgement, accountability or verification.

The false comfort of “it stays local”

The most important governance warning is this: “local” is an architectural claim, not a risk conclusion.

A model may run locally, but the broader system may still involve external calls, model updates, cloud dashboards, plug-ins, telemetry, hosted vector databases, external authentication services, remote support or third-party monitoring. An organisation should not say that confidential information “does not leave the organisation” unless that statement has been verified end-to-end.

Even where the system is genuinely local, several risks remain.

Accuracy and hallucination risk. A local model can still produce confident but wrong answers. Smaller or heavily compressed models may be less capable than leading cloud models for complex reasoning. Every material output needs a human owner and a verification standard.

Prompt injection and insecure output handling. If the model reads internal documents, it may also read hidden or malicious instructions embedded in those documents. Outputs can also create downstream risk if they are copied into emails, board papers, code, customer communications or regulatory responses without review.

Supply chain risk. Downloading model weights, model files, containers, libraries and plug-ins introduces provenance and integrity questions. The organisation needs to know where the model came from, what licence applies, whether commercial use is permitted, what dependencies are involved and how vulnerabilities are monitored.

Privacy and data governance risk. Local deployment does not remove Privacy Act, confidentiality, secrecy, surveillance, employment, customer-data or cross-border data obligations. It may reduce disclosure to an external AI provider, but it does not remove the need to justify collection, use, access, accuracy, security and retention.

Records, privilege and discovery risk. Prompts, outputs, retrieved documents, embeddings, logs and evaluation records may be business records. Some may be privileged; some may not. Some may be discoverable or subject to regulatory notice. Local control may make deletion technically easier, but evidence must not be destroyed where a preservation obligation, legal hold, regulatory investigation or proceeding applies.

Operational resilience risk. Local AI creates internal technology dependencies. Someone must patch, test, back up, monitor, upgrade, document, secure and eventually decommission the system. If it becomes business-critical, it belongs in operational resilience planning.

Cost and performance risk. The absence of per-token cloud charges does not mean the system is free. Hardware, energy, engineering, assurance, security, evaluation, support and opportunity costs matter. For light or occasional use, an enterprise cloud tool may be more economical. For high-volume or highly sensitive workloads, local deployment may be compelling.

The discoverability question

One issue deserves particular care: whether local AI changes the legal discoverability of AI prompts and outputs.

The safest answer is that it may change the mechanics, but it does not change the underlying discipline. A local system may give an organisation greater control over what is logged, how long records are kept and how data is purged. That can be useful for privacy, confidentiality and information governance. But it should not be used to avoid legal accountability.

If AI prompts or outputs are relevant to a dispute, investigation, decision, advice process or regulatory response, they may need to be preserved. If a legal hold is in place, deletion settings must not operate in a way that destroys potentially relevant material. If privileged material is used, access and handling must preserve confidentiality. If AI is used in legal or board processes, the recordkeeping rules should be settled before the system is used, not after a problem arises.

For this reason, any local AI deployment should have a records-retention and legal-hold design. The organisation should decide what will be logged, who can access logs, how long logs are retained, how prompts and outputs are classified, how privileged prompts are segregated, how legal holds override ordinary deletion and how audit trails can be produced if required.

What should the board ask?

A board does not need to become a machine-learning engineering team. It does need enough AI literacy to ask better questions and insist on adequate controls. Useful questions include:

What sensitive use cases are currently blocked because existing AI tools are not suitable?

Which data classifications are permitted in consumer AI, enterprise cloud AI and local AI?

Who owns AI risk, model risk, information security, privacy and records management for local AI?

What model is being used, under what licence, and from what source?

Has the model been tested on the organisation’s intended use cases, not just generic benchmarks?

What human review is required before an AI output is relied on or circulated?

What logs, prompts, outputs, embeddings and retrieved documents are retained, and for how long?

How do legal holds, regulatory notices and investigations override deletion settings?

What cyber, access, monitoring and incident response controls apply?

What happens if the local model fails, produces poor outputs, becomes unsupported or is superseded?

How will the board receive assurance that the policy is being followed?

The role of the company secretary

Company secretaries are well placed to help translate local AI from a technical project into a governed operating model.

That role may include updating the AI use policy, aligning AI permissions with the document classification scheme, clarifying board and committee paper rules, setting expectations for minute-taking and recordkeeping, coordinating director training, working with legal and IT on privilege and retention settings, and ensuring that AI-related decisions are captured in appropriate registers or governance artefacts.

The company secretary can also help prevent two common failure modes. The first is over-enthusiasm: adopting local AI because it feels private, without adequate testing and controls. The second is over-caution: prohibiting all meaningful AI use because legacy tools were not suitable. The better path is controlled enablement.

A practical control framework

Before using local AI for board or sensitive organisational work, management should be able to demonstrate that the following controls are in place:

Approved use cases. The organisation has identified what local AI may and may not be used for, with higher-risk use cases requiring formal approval.

Information classification. Permitted AI tools are mapped to data classifications, including clear rules for board-only, privileged, personal, market-sensitive and regulated information.

Architecture assurance. The organisation has verified whether prompts, outputs, logs, embeddings, telemetry, support data or administrative metadata leave the controlled environment.

Model provenance and licensing. Models are sourced from approved repositories or vendors, licence terms are reviewed, integrity checks are performed and dependencies are managed.

Access control. Use is restricted to approved users, with role-based access, authentication, audit trails and segregation for highly sensitive matters.

Human verification. AI outputs are treated as drafts or analytical aids unless and until verified by an accountable human.

Records and legal hold. Retention, deletion, audit logging and legal-hold overrides are designed before use.

Privacy and confidentiality. Personal information, client information, employee information and privileged material are subject to specific handling rules.

Security testing and monitoring. The deployment is tested for prompt injection, data leakage, insecure output handling, malware and unauthorised access.

Board reporting. The board or relevant committee receives periodic reporting on approved use cases, incidents, policy breaches, assurance findings and material changes.

A watershed moment - if governed properly

Local AI models may be a watershed moment for organisations that have been waiting for a safer way to use AI with confidential information. They may allow boards, executives and governance teams to obtain the benefits of AI in areas where consumer tools are plainly unsuitable and enterprise cloud tools may not be sufficient.

But the governance message is not “the model is local, so the risk is solved”. The message is “the model is local, so a new set of use cases may be possible, provided the controls are fit for purpose”.

The organisations that benefit most are unlikely to be those that simply pick one AI tool and declare victory. They will be the organisations that build an AI operating model: public tools for public work, enterprise tools for approved internal work, and local models for sensitive work where control, confidentiality and resilience matter most.

For boards and company secretaries, that is the real opportunity. Local AI can bring AI closer to the information that matters. Governance must bring the controls just as close.