Make the deployment understandable before it becomes technical.

On your premises—normally in a locked server room, network closet, or other controlled IT space with appropriate power, cooling, and physical access. The system sits inside your approved security boundary, typically on a dedicated AI VLAN or subnet; customer IT owns and approves the network design.

Approved on-site users reach one private HTTPS endpoint. Remote users follow your existing managed-device, MFA, VPN or ZTNA path, while administrators use a restricted management path. Skilak does not make the interface public or create a separate unmanaged tunnel.

Skilak stages the system on an approved network using synthetic or explicitly approved data. We lock the approved images and model revision, cache required artifacts, exercise the workload, verify a backup, and test offline restart. Final TLS, identity, firewall, data, and acceptance work happens inside your approved customer boundary.

Yes. The core AI workload is designed to operate from locally cached, image-locked artifacts. A fully disconnected design uses local accounts or a customer-local identity provider; cloud SSO, updates, monitoring, or support may require narrow, documented outbound paths that you approve and control.

The acceptance test records full IPv4 and IPv6 packets on a named boundary interface while an agreed workload runs, inventories every destination, and compares it with an explicit allowlist. A pass means no unapproved destination was observed on that interface, during that recorded time window and workload, against that allowlist. It is not a permanent or universal zero-egress claim.

The defined backup set covers the vector store, user, chat and upload state, monitoring history, dashboards, and active configuration; the model cache can be included for disconnected recovery. Backups are integrity-checked, but recovery is not accepted until a restore drill verifies the application, a planted document and citation, monitoring history, and restart behavior. You own the encrypted off-host target, retention, keys, and recovery objectives.

Yes. Models are selected against your workload, hardware capacity, quality threshold, licensing, and operating constraints, then pinned and cached for local operation. Before staging, Skilak verifies repository access, actual model size, runtime and quantization support, and room for the cache; open-weight does not mean every model has identical use rights.

You own the hardware and final credential custody, and you control the security boundary, network, identity, data, backup, logging, retention, and support authorization. Skilak hands over acceptance evidence and the installation, backup and restore, egress-verification, and network-access runbooks. The operating model does not depend on permanent Skilak access.

Support is selected and documented during delivery: scheduled on-site service for an air-gapped site; customer-created, time-limited, MFA-protected and logged VPN or bastion access; or a customer-assisted session where your administrator performs privileged actions. Skilak does not install a permanent remote-control agent, outbound tunnel, or unmanaged support account.

No. SkilakSpool is designed to fit within your CMMC, HIPAA, ITAR, or other security program; Skilak Consulting does not certify or confer compliance. Your security program retains responsibility for the boundary, policies, authorization, and assessor evidence, while Skilak supplies design, implementation, validation evidence, and operating runbooks.