Who looks after
on-premise AI?

Support starts in the quote

“Managed”, “supported” and “maintained” do not have one standard meaning. A support plan may cover the AI application but not the office network, backups or hardware repair. It may include remote diagnosis but not a promised restoration time. The buyer needs a responsibility map, not a reassuring adjective.

Write down the installed baseline: hardware, operating system, application version, model roster, context limits, accounts, connected services, backup target and acceptance results. Future support can then compare a problem with a known working state. Without that record, every call begins with discovery.

Divide responsibility before something fails

Those are starting points, not fixed legal roles. Put the actual split in the quote and handover. The Australian Cyber Security Centre publishes guidance for engaging managed service providers, including least-privilege administration and remote-access logging. An AI appliance supplier may not be the organisation’s general managed service provider, which makes the boundary even more important.

A practical maintenance cycle

Health

Check storage space, model loading, background services, errors, temperature or hardware alerts and completion of the agreed core jobs.

Security updates

Review operating-system, runtime and application fixes against exposure and urgency; test material changes before broad use.

Models

Keep the supported roster pinned. Assess a candidate’s source, licence, size, engine and accepted workload before replacing anything.

Accounts

Remove departed staff, review administrator access and confirm private and shared areas still match the office.

Network

Check local HTTPS, certificate dates, network placement, firewall or allowlist exceptions and any remote route.

Backups

Confirm the right data, application state and configuration are copied to the named target; then restore a representative item.

Capacity

Compare current users, documents, recordings and busiest-hour demand with the accepted baseline and remaining headroom.

Records

Update the configuration, change, incident and test records so the next check starts from facts.

The ASD Essential Eight includes patching applications, patching operating systems and regular backups. It is a general cyber-security baseline, not proof that an AI system is safe or that one maintenance frequency suits every business.

Patch deliberately, not casually

An on-premise AI appliance contains several moving parts: operating system, container or service runtime, application, model engine, model files and sometimes document or speech services. A security fix may be urgent. A feature release may be optional. A model update can change output even when the interface looks the same.

For each change, record:

• why it is needed and which risk or useful capability it addresses;
• the source, version and integrity information for downloaded files;
• which configuration or data needs protection before the change;
• the small acceptance set that must pass afterwards;
• who approves deployment and when staff will be told;
• how the previous state can be restored if the result is worse.

Automatic updates can reduce exposure for ordinary software, but blindly replacing a business model or workflow can change answers and break a tested route. Use a risk-based schedule: urgent security work gets urgent assessment; optional model changes earn their place by passing the real workload.

Monitor useful behaviour, not only uptime

A green service light proves the software is running. It does not prove a cited answer points to the right passage, a transcription remains usable or a template still produces the required format. Keep a short, approved acceptance set representing the jobs the business relies on. Re-run it after material model, runtime, application or configuration changes.

The Australian Government’s Guidance for AI Adoption implementation guidance recommends defined acceptance criteria, pre-deployment testing, monitoring relevant performance indicators and response processes for foreseeable issues. For a small office, this can be modest: five representative examples, named owners and a change log are more useful than a large dashboard nobody reviews.

Users remain part of monitoring. Give them a clear way to report a wrong answer, missing source, slow job or access problem, and record whether the issue came from the model, source material, permissions, capacity or workflow.

A backup is useful only when it restores

Decide what must be recoverable: source files where the appliance is authoritative, document index, conversations where retained, configuration, account records, model manifests and any custom workflows. Some large model files may be safely re-downloaded from a pinned source rather than copied every night; that decision should be documented, along with what happens if the source later changes or disappears.

Set the backup frequency from the amount of work the business can afford to lose. Set the recovery design from how long it can operate without the appliance. Protect backup credentials and keep at least one recovery path outside the failure that could take the machine. If off-site or cloud backup is chosen, that is a separate data path requiring its own destination, encryption, access and retention review.

ASD’s guidance on securing customer personal data says backups should be retained securely and resiliently and restoration regularly tested. A successful backup notification is not the same as a completed restore test.

Remote support should be narrow and visible

Ordinary use of a LocallyAI appliance does not need a standing remote session. When help is requested, the support connection is a separate path. Before enabling it, agree:

Start

Who at the customer can request and open a session?

Identity

Which named support person or account connects, and how are they authenticated?

Privilege

What is the minimum access needed for this job, and when is it removed?

Visibility

Can the customer see the session, and which connection or admin events are recorded?

Data

May logs, screenshots, files or database extracts leave the appliance? If so, where and for how long?

Finish

Who closes the route, confirms the change and records the result?

Remote delivery is practical across Australia because diagnosis and application work do not require the supplier to own the customer’s network. It does not remove the need for somebody on site when power, cabling, physical damage or a local sign-in blocks access. The support plan should name that local contact and the hardware repair path.

Support response is not recovery

“We respond within four hours” means somebody acknowledges the request. It does not promise a repaired machine or restored service within four hours. Ask separately about:

• support hours, contact channels and response targets by severity;
• remote diagnosis, on-site availability and travel charges;
• hardware warranty handling, freight and temporary replacement options;
• the amount of recent work that may be lost after recovery;
• the target time to restore the agreed minimum service;
• dependencies on the customer, IT provider, manufacturer or internet connection;
• what is excluded and how separately quoted work is approved.

LocallyAI does not publish a blanket uptime or recovery promise. The accepted quote governs the supplied support. Current public pricing lists an optional $600 yearly scheduled health check and tune-up; it is not compulsory and does not include unlimited support or update work.

Ownership with support, not ownership alone

LocallyAI keeps hardware, patching, backup and recovery visible instead of burying them inside an external platform. The supplied support route covers the installed system, while the handover record shows what the customer, LocallyAI and any IT provider each own.

That creates practical control: core work can continue without internet, changes can be acceptance-tested before release, and the business has export paths, administrator records and a documented recovery plan rather than total dependence on a provider’s continuing service.

Plan the end while the system works

Support eventually ends, hardware ages and business needs change. The handover should say how to export retained files and records, who holds administrator and recovery material, how support access is removed, which licences continue, and how storage will be securely reused or disposed of. A supported replacement should include migration and a new acceptance test rather than an unexplained copy of the old machine.

Good exit terms reduce lock-in without pretending the buyer can operate every component forever without skilled help. The useful standard is practical control: enough records, credentials and export paths to change supplier or retire the system safely.

Questions for a support proposal

Scope

Which hardware, software, models, workflows and locations are covered?

People

Who may request help, approve change, administer the system and see customer material?

Access

Is remote access standing or customer-started, and how is it limited, logged and closed?

Updates

Which changes are included, who approves them, what gets tested and what rollback exists?

Recovery

Who owns backup, restore testing, keys, spare hardware and incident coordination?

Targets

What response and restoration targets apply, during which hours, with which dependencies?

Price

What is fixed, hourly, per visit or separately quoted?

Exit

What can be exported, what support access is removed and what disposal help is available?

Earlier reads: local AI installation in Australia and hardware sizing for Australian business.