Designing an Operating Agreement for a Local AI Assistant

A fictional assistant with no appointed operating team

This Design study proposes an operating agreement for a fictional, local, read-only knowledge assistant. Authorized employees would use it to find approved internal procedures. The proposal concerns who may make changes, restrict use, suspend an affected path, resume service and retire it.

No organization, client, staff appointment, deployment or incident is represented. The operating agreement has not been adopted and its exercises have not been performed. The released research material is a preparation guide and a blank structured template, not an implemented governance system or evidence of operational readiness.

Describe the permitted task before allocating roles

The proposed assistant would explain supported procedures with links to permitted sources. It would not approve spending, alter a source system, make eligibility decisions or issue instructions to external equipment. A wider use would require a new scope decision and relevant evaluation.

The service boundary would include the user application, local serving configuration, retrieval pipeline, authorization, source downloads and human escalation. Technical ownership of one component would not automatically transfer responsibility for intended use or organizational risk.

NIST's GOVERN guidance addresses responsibilities, communication and authority in AI risk management. This study uses that planning principle. The five proposed accountabilities and six exercise briefs are original design choices, not a NIST-mandated operating structure or a claim of compliance. The referenced Playbook currently notes an ongoing framework update. [1]

Propose five accountabilities without inventing appointments

The service owner would be responsible for the bounded service purpose and material scope decisions. The operator would maintain the technical service and carry out actions within a documented mandate. The information owner would handle source authority, access-policy questions and relevant information lifecycle decisions.

An evaluation reviewer would scrutinize the evidence supporting a change or resumption decision. A risk escalation role would resolve issues outside the agreed local mandate. Those are role descriptions, not names, titles or claims that a real organization has accepted them.

The public template leaves each person's identity, delegate, contact route and authority evidence null. A later implementation would need to resolve role overlap and any independence requirement appropriate to the use. The author is not listed as the fictional service's owner or approver.

Write six decision exercises

The first proposed exercise asks who may adopt the initial permitted scope. The second concerns authorization to conduct a bounded evaluation. The third concerns promoting a changed configuration or source set. Each would need evidence references, a stated decision-maker and an attributable decision record.

The fourth exercise concerns an operator placing an affected path on hold under an already accepted mandate. The fifth concerns resuming that path after review of the issue and supporting evidence. The sixth concerns retirement and a documented replacement or closure route.

All six remain planned and unexecuted. Expected authority and required evidence in the template must never be copied into actual-result fields as though an exercise occurred. Actual decisions, people, timestamps, evidence and approvals remain unfilled.

Keep reliability policy separate from access and quality concerns

Google's example error-budget policy names review and approval roles and includes a route for disagreement. This proposal borrows the idea of a written decision policy. It does not adopt that example's game-service targets, thresholds or escalation titles. [2]

For the fictional assistant, a waiting-time problem, an unsupported answer and a possible access-boundary failure would be handled under separately declared criteria. No numerical availability, latency or quality objective is supplied. Those fields remain null until the service's accountable parties have justified them.

A protective suspension should have a defined scope and a user-visible consequence. Holding a comparison feature does not necessarily imply that every supported lookup is unavailable. A real interface and authorization implementation would be needed to enforce that distinction; none was built or tested here.

Make handoff and review observable

A future exercise would verify that the designated person and delegate can receive an issue, find the relevant record and explain their authority. Merely filling a contact field would not establish coverage. The proposed record should retain missed handoffs and disagreement alongside any successful decision.

For a material change, preserve the exact proposed use, configuration and evidence scope. The reviewer should identify unresolved findings and the decision-maker should record any limitation or refusal. Technical checks, accountable risk decisions and deployment execution should remain distinguishable events.

A retirement decision would also identify the user transition, integration changes and appropriate handling of data and records under the organization's policies. This study supplies no legal retention rule or deletion schedule and reports no completed decommissioning.

Preparation ready for accountable completion

The AM-RP-001 preparation pack links the guide and unassigned decision template. Offline structural validation checks that the five role slots and six planned exercises are present and that actual evidence remains blank. It executes no tabletop, model, service or permission scenario.

The companion essay explains the wider operating argument. The next step requires authorized participants, accepted mandates, current source and configuration records, justified objectives, actual exercise evidence and accountable review. DGX experiments, deployment effectiveness, peer review and researcher-account verification remain separate unfinished work.