Start with the governed system, not the stack

Most AI architecture discussions start too low. A team selects a model, an orchestration framework, a vector store, an agent protocol or a guardrail product, then tries to infer the governance model from the resulting stack. That reverses the dependency.

The architecture should start by defining the target system: how business intent becomes an approved AI use case; how ownership and risk decisions are assigned; how an initiative moves from experiment to operation; what evidence is required before and after release; what changes trigger reassessment; and which decisions cannot be delegated to the model or agent.

I call that target an Enterprise AI Operating System. It is not a product category. It is a governed environment in which AI capabilities can move from strategy to production while remaining observable, constrained, evidence-producing and continuously reassessable.

What L0 decides

L0 is the architectural statement of purpose and system shape. It answers a small number of questions that every downstream layer depends on:

  • What outcomes are AI systems allowed to pursue? Business objectives and use cases have to exist before model behavior can be judged useful.
  • Who owns decisions? Product, risk, security, privacy, operations and assurance roles need explicit decision rights rather than a generic “human in the loop”.
  • What is inside the governed boundary? Models, data, tools, external providers, human approvals, evidence stores and execution environments may cross different trust and organizational boundaries.
  • What lifecycle is governed? Discovery, qualification, approval, operation, change, monitoring, reassessment, suspension and retirement need to be visible states.
  • What must remain independently verifiable? Claims about safety, control effectiveness, compliance or business value should be supported by evidence that is not merely the system's own assertion.

These are architecture decisions because they determine what the rest of the system must be capable of representing and enforcing. If they are left implicit, each technical product will supply its own partial answer.

The standards support the problem, not this exact architecture

NIST AI RMF organizes AI risk management around GOVERN, MAP, MEASURE and MANAGE. NIST describes governance as cross-cutting and risk management as continuous across the AI lifecycle. That supports the need for lifecycle governance and organizational decision structures. It does not define the Enterprise AI Operating System architecture proposed here.

ISO/IEC 42001:2023 specifies requirements for establishing, implementing, maintaining and continually improving an AI management system. It supports the idea that AI governance belongs at organizational level and must connect policy, objectives, processes, risk and continual improvement. It is a management-system standard, not a technical architecture blueprint.

For systems that fall within its scope, the EU AI Act adds legal requirements that can include lifecycle risk management, documentation, logging, human oversight and post-market monitoring. Article 9, for example, requires a continuous iterative risk-management process for high-risk AI systems. That is legal evidence for applicable regulated systems; it should not be generalized into a claim that every AI system has identical obligations.

Interface 1: Strategy and portfolio

L0 defines the destination; L1 decides which initiatives are worth admitting into the journey. A use case should not become a portfolio commitment merely because a prototype works or a vendor demo is impressive.

The strategy and portfolio interface should make value, accountable ownership, expected evidence, risk tolerance, dependencies and exit conditions explicit. This prevents a common failure mode: technical teams inherit a vague mandate to “use AI” while governance teams are asked to assess systems whose business purpose and decision owner were never clearly defined.

The important separation is simple: business sponsorship is not technical qualification, and technical capability is not authorization to deploy. L0 makes that distinction part of the operating model before any tool selection.

Interface 2: Enterprise risk and decision governance

Not every decision belongs to the AI team. Risk appetite, acceptance of material residual risk, exceptions, legal applicability, major supplier exposure and investment trade-offs are enterprise decisions. The architecture therefore needs an explicit interface to Enterprise Risk & Decision Governance rather than burying those decisions inside model prompts, engineering tickets or product settings.

This interface also prevents a second category error: treating a governance platform as the governance system. A GRC product can store workflows, controls and evidence. It does not itself establish the mandate, taxonomy, risk ownership, escalation rights or decision authority that make those records meaningful.

The operating model should therefore preserve the chain from business objective → use case → accountable owner → risk decision → qualified capability → observed effect → evidence → reassessment. Different tools may implement pieces of the chain, but the chain is the architecture.

Why tool-first architecture fails

Tool-first design creates accidental authority. The orchestration framework becomes the workflow model. The model provider becomes the identity boundary. The vector database becomes the memory policy. The observability platform becomes the evidence model. A “human approval” button becomes the decision-rights model. None of those substitutions is necessarily wrong, but each is an implementation choice being promoted into architecture without an explicit decision.

That makes replacement expensive because changing a vendor changes the conceptual system. It also makes assurance weak because control claims become coupled to provider documentation. Provider documentation can explain how a feature works; it is not independent evidence that the organization's intended control is correctly designed or operating effectively.

A stronger pattern is to define durable architecture objects first—purpose, ownership, decision rights, lifecycle states, evidence requirements, trust boundaries and qualification conditions—then map products and frameworks into them.

What the Harness governs

The Harness is the control and coordination structure that carries those L0 decisions into operation. It does not “govern AI” by wrapping a model with filters. It governs the conditions under which capabilities are introduced, composed, authorized, executed, observed, changed and retired.

At L0, the Harness therefore governs five things conceptually:

  • Intent: the business purpose, use context and acceptable outcomes.
  • Authority: who may decide, approve, delegate, override or stop.
  • Lifecycle: how a capability moves through qualification, operation, change and retirement.
  • Evidence: what must be observed to support decisions, assurance and reassessment.
  • Boundaries: where responsibility, trust, data, execution and supplier dependencies change.

The downstream layers implement these commitments in more concrete ways: portfolio gates, continual-change controls, runtime orchestration, governed context, capability admission, identity and policy enforcement, evaluation and observability, and execution infrastructure. L0 does not replace those layers. It prevents them from becoming disconnected technical silos.

A practical architecture test

Before selecting a new AI platform, ask whether you can answer the following without naming a vendor:

  1. What business decision or outcome is this system intended to support?
  2. Who is accountable for the use case and who owns residual-risk decisions?
  3. What evidence is required before production use?
  4. What events require reassessment or re-approval?
  5. Which capabilities may act, on whose authority, and within what boundaries?
  6. How will the organization know that the deployed system still matches the approved system?
  7. What is the retirement or rollback path if assumptions stop holding?

If the answers depend on a specific product interface, the architecture is probably still too implementation-shaped.

Claim status

  • Established: lifecycle risk management, organizational governance and continual improvement are supported by NIST AI RMF and ISO/IEC 42001; applicable legal obligations may add specific lifecycle and oversight duties.
  • Architecture synthesis: defining an Enterprise AI Operating System with L0 Vision, L1 Strategy & Portfolio and Enterprise Risk & Decision Governance as explicit interfaces is my proposed operating architecture.
  • Implementation principle: durable concepts such as ownership, authority, lifecycle and evidence should be defined before mapping them to replaceable tools and providers.
  • Not claimed: that this architecture is mandated by ISO, NIST or the EU AI Act; that every organization needs identical layers; or that adopting the model proves compliance or control effectiveness.

Evidence base

  • NIST AI Risk Management Framework — voluntary risk-management framework; supports lifecycle governance and continuous risk management.
  • NIST AI RMF Core — describes GOVERN as cross-cutting and the GOVERN, MAP, MEASURE and MANAGE functions.
  • ISO/IEC 42001:2023 — AI management-system requirements and continual improvement.
  • Regulation (EU) 2024/1689 — legal requirements for actors and systems in scope; Article 9 addresses lifecycle risk management for high-risk AI systems.

Next in the series

The next L0 article moves from vision to boundary: Architecture Before Tools: Defining the Boundary of a Governed AI System. The question is where the governed system begins and ends when models, data, people, suppliers, tools and execution environments cross organizational and technical boundaries.