# AI-Native Operating Architecture for SMEs — Document Set Overview

| | |
|---|---|
| **Version** | v1.0 (Final) |
| **Date** | 2026-08-10 |
| **Scope** | Model operating and technology architecture for organisations with 1–500 employees |
| **Horizon** | Up to 24 months, calibrated to readiness, risk and size |
| **Status** | Reference model — adapt and approve locally |

---

## 1. Purpose

This document set defines a practical reference architecture and adoption program for an organisation that wants AI to become part of normal operations rather than remain a collection of employee chat tools and pilots.

The set covers:

- the target operating and technology architecture;
- a phased implementation plan;
- data, security and AI governance;
- benefits measurement and financial conversion; and
- the minimum evidence required before an AI-enabled workflow is allowed to act in production.

It is a **reference model, not a product recipe or a promise that every organisation will become fully AI-native in 24 months**. The normal Month-24 target is a governed, measured and orchestrated operating model (maturity L4 in Doc 01), with selective AI-native characteristics in the functions where the economics and controls justify them.

The title uses “SME” commercially. Legal and statistical definitions vary by jurisdiction; the S3 band includes organisations that some markets classify as lower mid-market rather than SME.

## 2. Target organisation profile

The model is designed for an organisation that:

- has **1–500 employees**, using the internal size bands in §6;
- operates a predominantly SaaS and public-cloud estate;
- uses Google Workspace or Microsoft 365 as its primary identity and collaboration estate;
- is a **buyer and integrator of models**, not a frontier-model developer;
- has conventional functions such as finance, sales, marketing, support, people, operations and possibly product/engineering; and
- is not subject to a control regime that requires a materially different reference architecture.

“Not heavily regulated” does **not** mean unregulated. Privacy, employment, discrimination, consumer, records, intellectual-property, cybersecurity and contractual obligations still apply. Health, financial services, government, defence, critical infrastructure, safety-critical operations and similarly regulated deployments require a separate overlay and may require different technology choices, validation and segregation.

## 3. What “AI-native” means in this model

AI-native is an operating condition, not a licence tier or a count of agents. An organisation is moving towards AI-native operation when the following are true in the relevant functions:

1. **Work is managed as outcomes and workflows.** Each production workflow has an owner, trigger, inputs, controls, outputs, service levels, fallback path and unit economics.
2. **Models advise; deterministic controls authorise side effects.** A model may interpret, classify, draft, plan or propose an action. Business rules, policy checks, approvals and the transaction executor determine whether an action is permitted and commit it safely.
3. **Every material actor and action is attributable.** Human users, logical agents, runtime workloads and approvers are distinguishable; authority is least-privilege, time-bounded and auditable.
4. **Authoritative data is accessible through governed interfaces.** Operational data remains in systems of record. Organisational knowledge is curated, permission-aware, attributable to sources and subject to freshness and deletion controls.
5. **Production AI is evaluated and operated like a service.** Each system has acceptance tests, production monitoring, incident handling, rollback or manual fallback, change control and retirement criteria.
6. **Economics are measured per outcome.** Capacity created, cash converted, quality effects and total cost of ownership are reported separately. Adoption and token use are inputs, not benefits.
7. **The organisation continuously redesigns work.** It removes, simplifies and standardises work before automating it, then uses production evidence to improve processes, controls and role design.

AI-native therefore does **not** mean maximum autonomy. A mature organisation often chooses deterministic automation or human judgment over an agent because that is safer, cheaper and more reliable.

## 4. Three distinct AI operating patterns

The documents deliberately distinguish three patterns that are often conflated:

| Pattern | Primary user | Typical purpose | Default control posture |
|---|---|---|---|
| **Employee assistant** | A person | Search, analysis, drafting, coding and individual productivity | User remains accountable; no unattended side effects |
| **Bounded AI workflow** | A function or process | Repeatable task with explicit inputs, outputs and controls | Production owner, evaluations, deterministic action boundary and operational support |
| **Autonomous action class** | A background workflow | Narrow, repetitive, low-impact action within hard limits | Exceptional; only after sustained evidence, continuous monitoring and immediate pause capability |

An employee assistant is not automatically a production agent. A production agent is not granted one blanket autonomy level: **execution mode is assigned per action class**.

## 5. The document set

| # | Document | Primary question |
|---|---|---|
| 01 | **Target Architecture** | What is the target technical and operating architecture, and what controls sit between a model and a business transaction? |
| 02 | **Phased Implementation Plan** | How should the capability and workflow portfolio be introduced, gated and scaled over up to 24 months? |
| 03 | **Data, Security & AI Governance** | How are AI systems, data, identities, tools, risks, incidents, affected people and suppliers governed? |
| 04 | **Benefits Realisation** | How are capacity, service, quality, cash benefits and total cost measured without double counting? |

## 6. Size bands used throughout

The bands set a default level of architectural depth, not a mandatory shopping list.

| Band | Headcount | Default posture |
|---|---:|---|
| **S1 — Micro / very small** | 1–20 | One primary sanctioned assistant; native SaaS AI and managed automation; fractional ownership; no custom platform unless a specific workflow pays for it |
| **S2 — Small** | 21–100 | Managed workflow capability; first bounded production agents; lightweight central logging; partner or fractional engineering; data platform only where use cases require it |
| **S3 — Medium / lower mid-market** | 101–500 | Small internal platform capability; standard action-control pattern; central model/API controls where justified; durable workflows; formal portfolio, assurance and benefits routines |

A highly technical 15-person software company may need selected S2 controls. A 200-person organisation with few knowledge workflows may not need the full S3 platform. Use the readiness and complexity triggers in Doc 02 rather than headcount alone.

## 7. Non-negotiable design positions

1. **Simplify before automating.** Remove unnecessary work, fix the source process and use deterministic automation before introducing probabilistic reasoning.
2. **Use the minimum sufficient autonomy.** T3 is reserved for narrow, reversible, low-impact and normally non-sensitive action classes. Open-ended autonomous operation is outside the target state.
3. **Separate reasoning from execution.** Models do not hold broad credentials or directly improvise transactions. They emit typed proposals; a policy and transaction layer validates and executes them.
4. **Identity is necessary but not sufficient.** A logical agent ID, a workload principal and a delegating user are separate concepts. User-facing access preserves the user’s downstream permissions; background workflows use narrowly scoped workload identity.
5. **MCP is an interface, not a security boundary or enterprise service bus.** Use it where an AI host needs a standard tool interface, with pinned protocol versions, explicit authorisation, input/output validation and policy enforcement. Native APIs, events and workflow integrations remain the default for system-to-system processing.
6. **Systems of record remain authoritative.** RAG, vector indexes, model memory and chat history are not systems of record and are never used as transaction truth.
7. **Permission-aware retrieval is necessary but incomplete.** Security trimming, source provenance, freshness, permission-change propagation and deletion from indexes are all required.
8. **Do not create a prompt-and-response data lake.** Audit logs record sufficient metadata and governed references to reconstruct material actions. Raw content is retained only for a defined purpose, for the shortest appropriate period, with redaction and access controls.
9. **Model changes are production changes.** Model, prompt, tool, data-source and policy changes require proportionate regression testing, controlled rollout and rollback.
10. **One primary assistant pattern per user cohort.** Do not buy overlapping enterprise assistants for everyone by default. Add specialist products only where incremental value exceeds licence, change and governance cost.
11. **Local evidence outranks generic productivity claims.** AI performance is task- and context-dependent. Every material workflow must earn its business case against a local baseline and quality guardrails.
12. **Capacity and cash are separate ledgers.** Time released is an operational benefit. It becomes a financial benefit only when a documented conversion changes an approved cost, hiring or revenue plan.

## 8. How to adapt the model

1. Confirm the applicable organisation profile and document the exclusions.
2. Complete the readiness assessment in Doc 02 Appendix B.
3. Establish the legal and contractual obligations register for the jurisdictions, employees, customers and data involved.
4. Select the size-band defaults, then override them using workflow volume, integration complexity, data sensitivity and risk.
5. Record the architecture decisions in Doc 01, including the action-control, identity, logging and autonomy-ceiling decisions.
6. Inventory sanctioned, embedded and shadow AI; select the primary employee-assistant pattern by cohort.
7. Shortlist workflows using Doc 02’s “eliminate → simplify → deterministic → AI-assisted → agentic” decision sequence.
8. Localise the governance thresholds, prohibited uses, records rules, approval authorities and incident obligations in Doc 03.
9. Build the local cost and benefits baseline in Doc 04 before committing to portfolio savings.
10. Re-plan the phases against business capacity. S1 may reach its appropriate steady state in 6–12 months and can use **Appendix A** as its working summary; S3 commonly uses the full horizon.

## 9. Interpretation of requirement words

Within the document set:

- **MUST** identifies a baseline control required for claimed conformance to this reference model.
- **SHOULD** identifies the normal position; deviations require a recorded rationale.
- **MAY** identifies an optional capability selected by need.

Product names are examples current at the review date, not endorsements. Procurement must revalidate product features, contractual terms, pricing, residency and integration maturity.

## 10. Reference baseline at 10 August 2026

The model is designed to be compatible with, and proportionate to, the following current sources of good practice:

- Australian Government, **Guidance for AI Adoption** (six essential practices);
- ASD’s Australian Cyber Security Centre and international partners, **Careful Adoption of Agentic AI Services** (May 2026);
- NIST **AI Risk Management Framework 1.0** and **Generative AI Profile (NIST AI 600-1)**;
- NIST **Cybersecurity Framework 2.0** and **Secure Software Development Framework 1.1**;
- ISO/IEC **42001:2023** (AI management systems), **23894:2023** (AI risk management) and **42005:2025** (AI system impact assessment);
- OWASP **Top 10 for LLM Applications 2026** and **Top 10 for Agentic Applications 2026**;
- Model Context Protocol specification dated **2026-07-28**, together with OAuth 2.0 Security Best Current Practice (RFC 9700);
- OAIC guidance on privacy and commercially available AI products; and
- jurisdiction-specific requirements, including the EU AI Act where the organisation is in scope.

Conformance to this model is not certification against any of those frameworks and is not legal advice.

## 11. Glossary

| Term | Meaning in this document set |
|---|---|
| **Action broker / transaction boundary** | Deterministic service that receives a typed proposed action, checks policy and authority, executes the permitted transaction idempotently, and records the result. |
| **Action class** | A specific type of operation with a defined scope and impact, such as “add an internal CRM note” or “post a three-way-matched invoice below a threshold”. Execution mode is assigned at this level. |
| **Agent** | A software component that uses a model to interpret context, choose or propose steps, and interact with approved tools within a bounded workflow. |
| **AI system** | The complete deployed system: models, prompts, data, tools, workflow code, policies, interfaces, people and operating procedures. |
| **AI system register** | Organisation-wide inventory of procured, embedded and built AI systems, their owners, purpose, risk, data, suppliers, tests and lifecycle status. |
| **Autonomy / execution modes (T0–T3)** | Retrieve → Draft → Act with approval → Autonomous within a bounded policy. They describe execution, not overall risk. |
| **Authoritative source map** | Record of which system, table, field or document class is authoritative for a business fact. |
| **Banked financial benefit** | A finance-validated change to an approved cost, hiring, revenue or cash plan, supported by evidence and net of attributable cost. |
| **Context** | Information supplied to a model for one execution, including instructions, retrieved data and tool results. It is minimised and labelled by trust level. |
| **Control plane** | Registries, policy, identity, deployment, evaluation, budgets, approvals and administrative controls governing AI execution. |
| **DLP** | Data loss prevention controls that detect or block sensitive data movement. |
| **DPIA / impact assessment** | Proportionate assessment of privacy and broader effects on people, groups and rights before deployment and after material change. |
| **Evaluation set** | Versioned representative, edge and adversarial test cases with expected outcomes or calibrated rubrics. “Golden set” is retained as an informal synonym. |
| **Gateway** | Optional control point for model API credentials, routing, quotas, version policy, traces and cost allocation. It does not make models behaviourally interchangeable. |
| **HITL** | Human-in-the-loop control in which an appropriately authorised person reviews a specific proposed action before execution. |
| **Idempotency** | Property that permits a transaction to be retried without creating a duplicate side effect. |
| **IdP / SSO / SCIM** | Identity provider / single sign-on / automated account lifecycle provisioning. |
| **iPaaS** | Integration platform used primarily for deterministic application workflows. |
| **Logical agent ID** | Stable registry identity for an AI system or workflow, distinct from the runtime credential and any human on whose behalf it acts. |
| **MCP** | Model Context Protocol, a standard interface through which an AI host can access declared resources and tools. It does not by itself supply least privilege, business policy or safe execution. |
| **Model memory** | Persisted information used across executions. It is treated as a governed data store, not an informal model feature. |
| **Policy decision point** | Deterministic component that evaluates whether a proposed action is permitted given identity, data, action, value, context and risk. |
| **RAG** | Retrieval-augmented generation: retrieval of governed sources to ground a model response. It is not a database or authorisation system. |
| **Security trimming** | Applying the effective permissions of the requesting principal at retrieval time so prohibited content is not returned. |
| **SoR** | System of record — the authoritative application or data field for a defined business fact. |
| **TCO** | Total cost of ownership, including licences, usage, implementation, integration, data, evaluation, security, change, support and decommissioning. |
| **Unit cost** | Net cost per completed and quality-accepted outcome, such as per invoice, ticket or proposal. |
| **Workflow owner** | Accountable business owner for the workflow’s outcome, controls, evidence, cost and lifecycle. |
| **Workload identity** | Short-lived, non-human runtime identity used by a background service or agent, scoped to its approved resources and actions. |

## 12. Change log

| Version | Date | Change |
|---|---|---|
| v0.1 | 2026-08-10 | Initial four-document model |
| v0.2 | 2026-08-10 | Added operating model, runtime sequence, ADR template, workflow catalogue, readiness assessment and evaluation guidance |
| **v0.3** | **2026-08-10** | Resolved the Month-24 maturity contradiction; separated employee assistants, bounded workflows and autonomous action classes; introduced a deterministic action-control boundary; separated logical, delegated and workload identity; narrowed MCP’s role; strengthened RAG, logging, evaluation, continuity and supplier controls; aligned governance to August 2026 guidance; and separated operational capacity from cash benefits |
| **v1.0** | **2026-08-10** | Final release. Adopted the v0.3 third-party review in full after independent verification of its August-2026 citations (MCP 2026-07-28, OWASP LLM and Agentic 2026 editions, ASD/ACSC agentic-AI guidance, EU AI Omnibus dates, Australian ADM transparency commencement). Corrected the review register’s readiness-dimension count (eight, not nine); added the S1 minimum viable pattern (00 Appendix A); added value-story presentation guidance (04 §2.2) and study-anchored productivity reference points (04 §12) |

---

## Appendix A — The S1 minimum viable pattern (1–20 people)

This appendix is the whole model at S1 scale. An S1 organisation should not attempt to run the program as written for S3; the four documents remain the reference when a question of detail arises.

### A.1 Do these seven things

1. **One assistant, business terms.** Choose one sanctioned assistant — suite AI or one enterprise chat product — on business/team terms with training-on-your-data disabled and central administration. Personal accounts never touch company data.
2. **Identity basics.** Universal MFA, a shared password manager, central billing, and a written joiner/leaver checklist that is actually executed on the day someone leaves.
3. **Sharing hygiene.** Lock external-sharing defaults, review "anyone with link" access on anything sensitive, and know who owns the Drive or SharePoint estate.
4. **A one-page policy.** Approved tools; data that must never be pasted into AI (customer records, financials, HR matters, credentials); verify before you use or send; how to report a mistake — no blame.
5. **Three sheets.** A systems/tools register, a workflow register and a benefits/cost sheet. Spreadsheets are fine; keeping them current is the control.
6. **Two or three workflows.** Screen candidates with eliminate → simplify → deterministic → AI. Prefer high-frequency, low-risk tasks with objectively checkable outputs. Baseline volume, touch time and cost before switching anything on.
7. **A monthly 30-minute review.** Adoption, quality problems, spend against value, and kill/keep decisions.

### A.2 Non-negotiables at any size

- Models draft; a person commits (T1 is the default). Any automated write action — even inside a vendor tool — needs the approval discipline and a way to switch it off.
- No agent or automation ever runs on a person's credentials.
- Capacity is not cash: time saved becomes money only when a bill, contract, licence or planned hire actually changes.
- If it touches customer money, bank details, employment decisions or legal commitments, a person decides — every time.

### A.3 Skip until a specific workflow pays for it

Warehouse, model gateway, custom RAG/vector stack, code-first agents, multi-agent frameworks, and self-hosted anything.

### A.4 A 6–12 month path

- **Months 0–1:** items 1–5 above; select workflows; capture baselines.
- **Months 2–4:** assistant adopted in earnest; first two workflows live as drafts and checks (T0/T1); measure against baseline.
- **Months 5–8:** keep what works, kill what does not; consider one vendor-managed T2 automation (for example invoice capture with owner approval) if the evidence supports it.
- **Months 9–12:** consolidate overlapping tools; bank any real cash effects (subscriptions cancelled, outsourced work reduced); decide what year two looks like.

### A.5 When to graduate to S2 controls

Triggers, not headcount: the first custom write-enabled automation; grounding C3 data beyond suite-native capability; a workflow whose failure would materially harm a customer; or more than roughly five production workflows.