FIELD GUIDE / PRIVATE AI
Before you deploy AI,
define what it can touch.
Private AI readiness and deployment guide
A useful AI pilot begins with a real task, a defensible data boundary and a way to know when it fails. Use this guide to turn those decisions into an operating plan.
Build your deployment briefTHE STARTING POINT
Write the job before choosing the model.
“Help staff find the current approved procedure and show its source” is a testable job. “Put AI everywhere” is not. Choose one workflow whose owner can recognize a correct answer and whose failure can be contained.
This is Z7’s practical planning method, informed by the sources linked throughout. It is a deployment workbook, not a certification or a claim that any specific configuration is secure.
Workflow. Business owner. Intended users. Approved data. Allowed actions. Failure that would make you stop.
DATA BOUNDARIES
Private describes a boundary.
Make yours visible.
A model running on your hardware answers only one question: where inference happens. Retrieval, embeddings, tools, diagnostics and support can still create other data paths.
Planning map. Select a boundary to inspect it. Colors identify roles, not verified deployment health.
Access and approval
Enforce document and tool permissions outside the model. Keep consequential actions behind the agreed approval step.
| Deployment choice | What to verify | Tradeoff to include |
|---|---|---|
| Local inference | Model, retrieval, logging, backup and support paths stay within the approved boundary. Check outbound connections. | You own capacity planning, hardware resilience and the model operating lifecycle. |
| Hosted model with enterprise controls | Exactly which prompts, retrieved passages and tool results reach the provider, plus retention, region, access and contract terms. | Provider capability and availability come with external processing and usage dependencies. |
| Hybrid routing | A rule for each data class and task, enforced before a request leaves the environment. No silent fallback across boundaries. | More flexibility requires more policy, testing and operating complexity. |
Inventory every copy
Follow a document through upload, parsing, embeddings, retrieval, prompt context, response, logs and backup. Name the location, owner, retention rule and deletion process at each step. Treat exported diagnostics and support attachments as data flows too.
Read terms at the feature level
Training use, retention and access are separate questions. Do not infer one from another or carry a promise from a consumer product into an API deployment. Check the selected feature and your agreement. Anthropic’s API retention documentation illustrates why feature-specific review matters.
A data-flow inventory, approved destinations, tested outbound restrictions, retention settings and the person who approves a new connector.
IDENTITY AND ACTIONS
Retrieval must respect the person asking.
A shared knowledge index must not become a shortcut around document permissions. Enforce access in the retrieval and tool layers, then test it with real roles.
Retrieve only allowed content
Check permissions before content reaches the model. Test users in different departments, revoked access and documents that move between groups.
Keep output reviewable
Show the sources used. Make unsupported answers visible. Give the reviewer enough context to accept, revise or reject the draft.
Authorize the operation
Use scoped service identities and a separate approval step for consequential actions. Validate tool inputs and enforce permissions outside the prompt.
Retrieved documents and websites can contain malicious instructions. Treat them as untrusted input. A filter or a system prompt alone does not establish an authorization boundary. These controls follow OWASP’s prompt-injection guidance.
A role-to-data matrix, tool permissions, denied-access results, revoked-user results, approval records and an emergency way to disable actions.
EVALUATION
Evaluate the work.
Inspect the failures.
A fluent answer can still be wrong, unsupported or inappropriate for the user. Build a repeatable evaluation from approved examples of your actual work.
| Test family | Example task | Record |
|---|---|---|
| Known answer | Find a current procedure and cite the passage supporting it. | Correctness, source match, source version, reviewer decision. |
| Missing or conflicting evidence | Ask something absent from the approved library, or provide two conflicting procedures. | Whether the system identifies uncertainty and asks for review. |
| Unauthorized access | Ask for another department’s restricted record using a low-privilege account. | Denied retrieval and absence of restricted text in the response. |
| Manipulated content | Place an instruction to disclose data in an approved test document. | Unexpected tool use, attempted egress and enforceable denial. |
| Operational failure | Make a tool unavailable, revoke a credential or repeat a write request. | Safe failure, escalation, duplicate-action handling and recovery. |
| Representative load | Run the actual mix of tasks at expected concurrency and document sizes. | Queue time, completion latency, memory use, failures and review effort. |
Set the pass criteria first
Choose thresholds with the workflow owner. Define what is unacceptable even if the average score looks good. A single unauthorized disclosure should not disappear inside a high overall accuracy number.
Keep a versioned record
Record model, prompt, retrieval settings, data version and tool configuration with each run. Repeat affected evaluations after a change. Keep test examples separate from tuning examples so the comparison remains useful.
NIST’s AI Risk Management Framework provides a broader structure for identifying, measuring and managing risk. This worksheet translates those concerns into concrete project evidence.
Approved evaluation set, expected behavior, pass criteria, actual failures, reviewer sign-off and the configuration tested.
OPERATING ECONOMICS
Local inference still has an operating cost.
Compare the cost of useful completed work. A token price, hardware price or fast demo is not a full operating budget.
Infrastructure + software + model usage + operations + review + resilience
Planning categories, not a quote or a savings claim.| Category | Assumption to collect | Who verifies it |
|---|---|---|
| Infrastructure | Lease or amortization, memory, storage growth, network and power. Include idle capacity. | IT and finance |
| Software and model use | Deployment rights, licenses, hosted usage, embeddings, reranking, OCR and connector costs. | Technical owner and procurement |
| Operations | Administration, patching, model updates, evaluations, integration maintenance and support. | Service owner |
| Human review | Review time, corrections, escalations and training measured during the pilot. | Workflow owner |
| Resilience | Backup, restore testing, spare capacity and the agreed recovery requirement. | IT and business owner |
Write three workload scenarios
Estimate normal demand, expected growth and a busy period. Include concurrent users, tasks per user, document size, input and output volume, acceptable wait time and whether an agent takes multiple steps.
Compare like for like
Divide total operating cost by accepted completed tasks for the same period. Track unsuccessful attempts and review effort too. Compare options using the same quality, availability and data-handling requirements.
An assumption sheet with units, source, owner and date; pilot measurements; quoted costs; and sensitivity to workload growth. Label estimates until measured.
OPERATIONS AND SUPPORT
Name the owner of the difficult day.
A working pilot is the beginning of operations. Decide who responds when retrieval is stale, an integration fails or a model change alters the answer.
Before a change
Record the current configuration, evaluation baseline and known limitations. Agree on the update window, approver and rollback trigger.
During an incident
Define how to disable tools or the service, preserve relevant evidence, notify the owner and continue the workflow manually.
After recovery
Confirm restored permissions, data and integrations. Repeat affected evaluations before resuming the full workflow.
Document service hours, response targets, maintenance, exclusions and responsibility for customer-owned systems. Separate a response target from a recovery commitment. NCSC’s secure-deployment guidance recommends incident preparation and evaluation before release.
Support matrix, escalation contacts, backup and restore result, change log, rollback procedure and a tested manual fallback.
RELEASE DECISION
Expand when the evidence supports it.
Review the six evidence sets together. A promising task demonstration does not offset missing access tests or an unowned support obligation.
Begin with a limited pilot using approved data and users. Expand only after the owner accepts the results, remaining limitations and operating responsibilities. Keep privacy, records and legal reviewers involved where the data or use case requires them.
The broader CISA and NCSC secure AI lifecycle guidance reinforces that design, deployment and ongoing operation belong in the same plan.
REFERENCES AND NEXT STEPS
Keep the source close to the claim.
Sources reviewed October 25, 2026. Provider features and terms can change. Verify the version and agreement selected for your deployment.
- NIST AI Risk Management Framework
A framework for organizing AI risks and responsibilities.
- NCSC: Secure deployment
Infrastructure protection, incident preparation and release evaluation.
- OWASP: Prompt Injection Prevention
Untrusted content, tool permissions and layered defenses.
- Anthropic: API and data retention
Feature-specific handling and eligibility. Check the actual product and agreement.
- CISA: Guidelines for Secure AI System Development
Secure design, development, deployment and operation.
Turn the brief into a scoped pilot.
Bring one workflow and the decisions above. Z7 can help with architecture, implementation, evaluation, training and an operating handoff.