An AI assistant should not discover its role, sources and authority while handling live work. Define the operating contract first.
Teams often spend more time naming an AI assistant than defining what it may do. It gets a friendly identity, a polished interface and access to company files. Its actual operating instructions end up scattered across a system prompt, workflow settings, platform permissions, unwritten team expectations, and whatever the first user asks.
That is not an operating model.
Before the assistant handles real work it needs a human-readable manual stating purpose, authority, approved evidence, prohibited actions, validation, escalation, record-keeping and ownership.
The manual is not the system prompt. It is the source from which prompts, permissions, tests and review procedures are derived.
Why the prompt is not enough
A prompt can influence model behaviour. It is not a reliable security boundary.
External content can attempt to redirect a model through prompt injection. Users can request actions outside the intended scope. Platform settings may grant access the prompt says not to use. A model can also simply misinterpret an instruction.
OWASP’s guidance warns against relying on model instructions to protect sensitive information or enforce permissions. Strong access control belongs in code, identity systems, tool permissions and workflow rules.
The manual serves a different purpose. People can review it. Owners can approve it. Testers can derive cases from it. Operators can recognise boundary violations. Changes can be versioned. Auditors can compare intended and actual operation.
If the only complete description of the system is inside the system, governance has failed.
The Assistant Operating Charter, twelve sections
1. Identity. System name, owner, technical operator, business area, version, deployment date, current status. The owner is accountable for continued fitness; the technical operator maintains it. Those may be different people.
Avoid anthropomorphic descriptions such as “our brilliant new teammate.” State what it is: an internal software system that retrieves approved records and drafts project-status summaries for human review.
2. Purpose. One primary purpose. “Reduce the time required to prepare the weekly project-status review while preserving source traceability and human approval,” not “help the team work better.” The purpose determines which data and permissions are necessary, and makes scope creep visible.
3. Users. Authorised user groups, required training, permitted markets or entities, access restrictions, and who may approve actions.
The EU AI Act’s literacy obligation has applied since 2 February 2025. Under the wording introduced by Regulation (EU) 2026/1744, providers and deployers must take measures supporting AI literacy among staff and others operating systems on their behalf, accounting for background, use context and affected people. A generic one-hour course does not automatically prepare someone to operate a system connected to contracts, customer records or publishing tools.
4. Inputs. Accepted sources, required fields, prohibited data, retention, validation, treatment of external content. Data minimisation is an operating principle, not a legal paragraph added later. If the assistant can perform the purpose using a project ID, it does not need a person’s entire message history.
5. Source hierarchy. Rank which evidence wins when sources conflict: signed current agreement, approved change order, current system-of-record status, approved project brief, internal working notes, historical examples. The assistant must not silently merge contradictions. It should show the conflict and escalate.
6. Permitted work. Specific verbs with specific objects. “May draft an internal project-status summary. May not send it to a client.” “Assist with project communication” is too broad to test.
7. Prohibited work. Explicit exclusions: no legal, medical or financial judgment, no employment decisions, no public publishing, no transfer of money, no deletion of source records, no change to approved scope, no access to unrelated folders, no invention of missing facts, no action based solely on general model knowledge.
The exclusions should include plausible requests, not only extreme ones.
8. Authority. Assign a level from the ladder in automation, assistance and delegation, then define approved tools, permission scope, monetary or volume limits, hours of operation, rate limits and confirmation requirements.
The permission implemented in the connected system must match the manual. A prompt saying “do not delete” is not an adequate control if the assistant still holds a broad deletion permission.
9. Output contract. What every output must contain, and must not. For a status assistant: project identifier, reporting period, current status, completed work, open decisions, blockers, a cited source for each factual statement, a missing-information notice, a draft label. Never invented dates, inferred approval, unsupported blame, or private notes outside the authorised audience.
10. Validation and escalation. Automated checks, human review, sampling rate, stop conditions, escalation recipient, response time, recovery procedure.
Stop when two approved sources conflict, a required record is missing, the request exceeds scope, sensitive information appears, a connected tool returns an unexpected result, or output validation fails twice. Escalation should preserve the evidence already gathered. A person should not have to reconstruct the case.
11. Logging and retention. Record what triggered the system, which version ran, which sources it used, what it produced, what action it took, who approved it, what was corrected. Then define a retention period and access policy.
Do not log complete sensitive inputs by default. Logs become a second data store with weaker controls than the system of record.
12. Change and shutdown. Who may change instructions, who may change tools or permissions, testing required before release, version naming, rollback, emergency stop, conditions for retirement, export and deletion procedure.
An assistant without a shutdown procedure is unfinished.
Turn the manual into tests
Every permission and prohibition generates a test case. If the manual says the assistant must not send client emails, use expired policies, expose private project notes, or act when sources conflict, then the evaluation set must attempt each behaviour.
Include normal requests, incomplete requests, requests outside scope, conflicting sources, malicious instructions inside documents, attempts to access another user’s data, tool failures and repeated actions.
Test the complete system, not only the model’s answer. A correct refusal followed by an incorrectly executed tool call is still a failure. This is the evaluation set described in turning a repeated task into a reliable workflow.
Publish a one-page operator card
The full manual supports governance. Daily users need a shorter reference showing what the assistant does, what it does not do, approved inputs, authority level, how to verify output, how to report a problem, how to stop an action, the owner and the version.
Place it where the system is used.
Review when reality changes
Trigger a review when the base model changes, a new data source is connected, a new tool is added, authority increases, the workflow enters a new market, a material incident occurs, output quality drifts, or the business process changes.
A system can remain technically identical while its risk changes, because the surrounding process changed.
How we use it
We treat the Assistant Operating Charter as a required deliverable for every internal or client AI system, approved before live access is granted. It generates the prompts, permissions, evaluation cases, operator training, monitoring and escalation.
That makes the work transferable. A new operator can understand the system without reading a developer’s mind. A client can see what has and has not been delegated. A future platform can be evaluated against the same contract. It is the same reason Origin writes brand systems to be operated by someone who was not in the room.
The assistant’s first task is not answering a question. It is staying inside the role it was given.
If you are about to give an assistant access to company files, tell us what it will be able to reach and we will tell you what the charter needs to say.
Sources
NIST AI Risk Management Framework Core.
NIST Generative AI Profile.
OWASP Top 10 for Large Language Model Applications.
European Data Protection Board, data protection basics for small business.
CISA and NCSC, Guidelines for Secure AI System Development.
Regulation (EU) 2026/1744 amending the AI Act.
Current to 30 July 2026. This article provides an operating framework, not legal advice.
