A Private AI Service Needs Clear Decision Rights

The pilot has an evaluation scorecard, a working endpoint and a group of interested users. Then the person who built it goes on leave. A source document changes, an answer is challenged, and a request arrives to open the assistant to another department. Who can make each decision?

A private AI service needs an operating agreement that survives that handoff. Infrastructure control is useful, but ownership also means knowing who can change the service, restrict its scope, suspend an affected function and decide whether it may resume. This essay develops those decisions through a fictional internal knowledge assistant. It reports no customer deployment, incident, assigned staff or measured reliability outcome.

Own a bounded service, rather than a machine

Describe the task people may rely on. In this proposed assistant, authorized staff could find approved procedures and receive source-backed explanations. It would not approve expenses, determine public-service eligibility or act on external systems. The operating agreement should make those exclusions discoverable to users and maintainers.

Identify the complete service boundary: the application, model-serving configuration, retrieval sources, identity checks, source-download route and escalation path. Different people may maintain those components, but users still need a responsible service owner. A hardware custodian cannot automatically decide what the organization is willing to rely on.

NIST's Playbook connects AI risk management with documented responsibilities, communication and delegated authority. Its GOVERN guidance supports making those relationships explicit; it does not prescribe the five-role proposal used here or certify this design. The current page also notes that the framework is being updated. [1]

Write decision rights alongside responsibilities

A responsibility such as monitoring quality is incomplete without an action boundary. Can the person who detects a problem restrict the affected feature? Must a particular owner authorize a wider rollout? Who resolves a disagreement about whether evidence is sufficient?

For a small service, start with five proposed accountabilities: service ownership, technical operation, information ownership, evaluation review and risk escalation. One person might hold several roles, but document that combination and any conflict it creates. A role label in a diagram is not an actual appointment or a working contact route.

Record the person, delegate, scope of authority and evidence of acceptance separately. Keep authority to approve intended use distinct from permission to execute a routine configuration change. A maintainer may know how to deploy a model without being authorized to expand what employees may use it for.

Agree on what happens when evidence deteriorates

Operational decisions need triggers and an escalation path. A source that becomes unavailable, a disputed answer, an access-control concern and excessive waiting may require different responses. Avoid one vague instruction to escalate all problems to leadership.

Google's published error-budget policy example connects reliability decisions with named review and approval roles and a disagreement route. The useful pattern is to define the action and authority before a dispute. Its example service and thresholds are not targets for this proposed assistant. [2]

Separate availability objectives from quality and access boundaries. A service could be reachable while producing unsupported answers. An access concern should not be treated as an acceptable allowance merely because an availability budget remains. State when a narrow function should be placed on hold and which evidence is needed for a subsequent decision.

Give the operator a usable mandate

An operator who must seek a new executive decision before every protective action may be unable to apply the intended operating policy. Define a bounded authority to suspend an affected path under stated conditions, retain records and notify the appropriate owner. This is a proposed arrangement that requires actual authorization before use.

The same policy should identify what the operator cannot change alone. Restoring a process, changing a source set and expanding the permitted use can carry different consequences. Document the permitted actions and their limits instead of relying on informal access to an administrator account.

Plan for absence. A delegate needs the relevant access, context and accepted responsibility, not just a name in a spreadsheet. A proposed contact route should be checked during an authorized exercise before it is described as operational coverage. No such exercise has occurred here.

Preserve the basis for a change decision

For a material change, record the proposed scope, configuration revision, relevant evaluation evidence, unresolved issues, decision-maker and date. Preserve the result of the decision, including a refusal or a narrower authorization. A passing technical check cannot supply the missing organizational decision.

Independent scrutiny is particularly useful when the same person builds and promotes the service. A small team may not be able to separate every role. Make the overlap visible and arrange a proportionate review route, rather than inventing a committee or claiming independence that does not exist.

Keep the user-facing description aligned with the authorized scope. If a comparison feature is suspended but document lookup remains available, people should be able to see that difference. Silent scope changes make both user expectations and later incident review harder to interpret.

Include retirement in the agreement

Some services should be replaced, narrowed permanently or retired. Identify who decides that the service no longer has an adequate purpose, support arrangement or evidence base. Plan how users find the replacement route and how access, integrations, source copies and retained records are handled under the relevant organizational policies.

The companion Design study proposes a compact decision record and six planned exercises. The research pack supplies an unassigned template and preparation guide. They appoint nobody and authorize no operation. The next milestone needs real accountable people, accepted mandates, justified objectives and attributable exercise records.