What it takes to operate local AI.

Give the assistant an operating plan.

1. Access. Use individual identities and enforce document permissions during retrieval. Review service-account access and remove it when no longer needed.
2. Data flow. Inventory the model, connectors, indexes, logs, telemetry, and backups. Verify which components can communicate outside the intended environment.
3. Answers. Show supporting sources where the task needs evidence. Test whether the cited passage actually supports the answer. Citation formatting alone does not establish correctness.
4. Actions. Start read-only. Any later ability to send a message, edit a record, or call a tool needs separate authorization, validation, and an appropriate approval step.
5. Recovery. Back up configuration and necessary data, protect the copies, and restore a test environment. Define the fallback when the service is unavailable.
6. Ownership. Assign updates, monitoring, user support, incident handling, and the authority to disable the assistant.

Minimize sensitive information in logs and define retention deliberately. Test for accidental disclosure through chat history, exports, and shared devices as well as through the model itself.

Before launch, ask the operator to demonstrate a denied request, a removed user's access, a failed dependency, and a recovery. These are practical acceptance tests, not a guarantee against every failure.

Price the whole first year.

A local model can reduce reliance on per-request provider charges. It does not make the service free to operate.

• Setup: hardware or hosting, integration, document preparation, identity, and evaluation.
• Recurring work: electricity or compute, support, security updates, monitoring, and staff time.
• Resilience: backup, spare capacity, replacement hardware, and tested recovery.
• Quality: human checking, model updates, failed answers, and retraining users when the workflow changes.

Compare options using the same workload, quality target, number of users, and support expectations. Show assumptions separately from measured results. Avoid a hardware-price comparison against a hosted service that includes work you would still need to do yourself.

Mutiny's role can be to define the use case, build and test the integration, and agree an operating handoff. Ask for the test results and responsibilities in the proposal. Discuss a bounded pilot →