The internet goes down, but an employee still needs a contract clause, a draft reply and a view of urgent assignments. If the necessary data and models are local, some work can continue. “Offline AI” does not mean the company can survive every disruption without interruption.

Loss of connectivity, power failure, a broken station and an inaccessible office are different events. Each needs its own continuity and recovery approach. A compact local AI server can help, alongside tested backup power, connectivity, copies and operating procedures.

Define offline capability by function

Replace a broad promise with a list of operations that must remain available: searching saved documents, answering from a local knowledge base, drafting and viewing the last synchronised management snapshot.

Check the entire path. A local language model is insufficient if OCR uses an external API, retrieval needs a cloud index or sign-in depends on an unavailable identity service. Validate dependencies on the chosen configuration.

Availability and freshness are different. Yesterday's price list may open offline without becoming today's price list. Show data age and do not imply a fresh external check.

An employee at home cannot automatically reach an office station whose internet link has failed. An autonomous workplace needs data and computing accessible where work actually continues.

Four failures require different responses

Different failures need different preparations
EventWhat may remainSeparate requirement
Internet unavailableValidated local functionsBackup link or offline mode
Power unavailableOperation within battery reserveUPS for required load, controlled shutdown
Station failureAccessible independent copiesReplacement or prepared secondary node
Office inaccessibleData and services outside the siteSafe alternate location, access and recovery

These are general design distinctions, not guaranteed capabilities of a particular hardware package. Actual incident actions must respect personal safety and company procedures. Staff should not retrieve equipment from an unsafe location to preserve service.

The business needs priorities: which functions cannot be lost for long, and what reduced service is acceptable? Document and contact access may be enough in one case; another may require a prepared secondary node with current data and integrations.

What can remain available offline

A local model with preloaded files and a fully local environment can process authorised documents within validated limits. This does not automatically extend to new email, external CRM, banking or other network services.

A reduced-connectivity mode should separate available actions, such as opening a saved contract, drafting a message or creating a local note, from network-dependent work such as checking current stock or sending an email.

Show the operating mode and last synchronisation time. A check that never ran must not appear as current. Stale inventory or transaction state can mislead decisions if the loss of connectivity is hidden.

Validate local access duration and authentication too. Security rules need an agreed continuity design rather than being switched off during an incident.

Mobile backup depends on an available network

A SIM-equipped router supporting the locally available network standard can provide an alternate internet path. A 5G label does not guarantee coverage, bandwidth or independence from the original outage.

Test operators, signal, plan restrictions, power and actual access to required services at the backup location. Two channels can share infrastructure. Switching paths can also interrupt active connections, so integrations need separate checks.

A mobile router cannot restore a network that is entirely unavailable. A defined local mode remains useful: prepare what can be prepared and retain external actions in a visible queue or for a later decision.

Changing operator must not change data policy. A document barred from an external AI API remains barred on the backup connection.

Size UPS protection for the complete setup

An uninterruptible power supply can support limited operation or enable a controlled shutdown. Runtime depends on the particular device, battery condition and connected load. A power rating does not itself specify hours of operation.

Include the station, networking and anything else required for access. A powered server is of limited use if its switch and access point are off. A laptop may have its own battery while an external display does not.

Choose equipment using manufacturer specifications and test realistic load. Define the response to low charge: pause heavy background work, preserve state and shut down correctly. Decide whether the aim is to bridge short interruptions or provide time to move to another operating mode.

Battery maintenance and UPS signalling belong in operations. A total discharge should not be the first test of automatic shutdown.

Backups and secondary nodes solve different problems

A backup restores data after loss or corruption. A secondary node can reduce time to resume work if it is prepared, compatible and sufficiently current. Buying another box does not create automatic failover.

Replication is not a replacement for backup history. Accidental deletion or corruption can spread to both nodes. Separate version-retention, access and recovery-testing rules are needed.

CISA recommends offline, encrypted backups of critical data and regular tests of availability and integrity during recovery. For local AI, this includes the data and configuration required to restore the working process, beyond documents alone. CISA · StopRansomware Guide

Define backup contents from the architecture: documents, assignment records, permission settings, integration configuration and necessary components. Secrets and keys need protected recovery. A search index may be rebuildable, but rebuilding time still belongs in the plan.

Set recovery time and data-loss objectives

RTO is the target recovery interval. RPO defines the acceptable recovery point for data, expressing how much recent change may be lost in time terms. These are design and testing objectives, not promises created by attaching a backup drive.

NIST's information-system contingency planning guide addresses priorities, recovery strategies and testing. It was written for US federal systems; its approach is used here as a methodological reference, not a mandatory requirement for Russian businesses. NIST · SP 800-34 Rev. 1 Contingency Planning Guide, updated edition

In a hypothetical case, the company wants document access restored within four hours with no more than one hour of changes lost. Copies must be sufficiently frequent, accessible under the chosen failure scenario and restorable with permissions within the target. A backup schedule alone does not establish this.

Different functions can have different objectives. The business and technical team decide whether a reference library or a critical assignment register takes priority.

Prepare the alternate workplace in advance

A compact station can make another workplace easier to organise. Moving the computing unit alone is insufficient: it still needs power, networking, access, current data and instructions for whoever starts it.

A backup stored beside the primary server can be lost with the same premises. Consider separate locations alongside data protection and key management. The design depends on budget and acceptable risk.

AI Office considers a portable secondary node with a limited data set and later synchronisation as a possible additional module. Its presence and operating mode are agreed separately; it is not automatically included in every initial package.

Prepare a short procedure covering who declares backup mode, where equipment is located, how data state is checked, what actions are allowed and who approves normal operation again. Keep the procedure accessible when the primary server is unavailable.

Reconnection is part of recovery

Local work may create new drafts and changes. Once the network returns, do not blindly execute everything accumulated: some actions may have been completed manually, become outdated or conflict with the external system.

Retain origin and state for queued actions. Before synchronisation, check duplicates, changed conditions and renewed approval requirements. Conflicts need a defined resolution process rather than a universal last-write-wins rule.

Show what synchronised, what remains local and what needs a decision. An internet connection coming back does not automatically restore the whole workflow to a correct state.

Test AI Office continuity in a pilot

Use an agreed test environment to remove external connectivity, exercise claimed local functions and record unavailable ones. Separately test power handling and recovery from backup through a safe procedure. These are different tests; one screenshot of a working chat cannot replace them.

Measure time to enter backup mode, available data age, completed operations, recovery duration and queue behaviour after reconnection. Document limitations and maintenance responsibilities.

Local AI can be a useful part of business continuity when the company knows which work continues, on what data and how normal operation resumes. That verifiable scenario is the right starting point for autonomous AI Office design.