The product boundary is rarely the governance boundary
Enterprise AI systems are assembled from components that sit in different technical and organizational domains: internal applications, external models, retrieval systems, human reviewers, tools, identity providers, cloud services and supplier APIs. Drawing the system boundary around one product hides the relationships that create responsibility.
The better question is not “where is the model hosted?” but “which chain of decisions, data and effects is the organization relying on?” A supplier can sit outside the corporate perimeter while remaining inside the system dependency model. A human approver can sit outside the software boundary while remaining inside the authority chain. An external tool can be technically remote while remaining part of the consequential execution path.
The governed boundary therefore needs several views rather than one box on a diagram.
Six views of the governed boundary
I use six views at L0. They are an architecture synthesis, not a taxonomy prescribed by NIST, ISO, OECD or the EU AI Act.
- Purpose boundary. What business objective, decision or service is the AI system intended to support? A component used for a materially different purpose may require a different governance decision even if the technology is unchanged.
- Responsibility boundary. Which legal entity, business owner, supplier and operator is responsible for which part of the outcome? Outsourcing execution does not automatically outsource accountability.
- Data boundary. Which information enters, leaves or is derived inside the system, under which classifications, jurisdictions, retention rules and supplier terms?
- Authority boundary. Who may recommend, approve, delegate, invoke, override or stop consequential actions? Possession of a capability is not the same as authority to use it.
- Execution boundary. Where do actions actually take effect—inside an application, cloud environment, supplier service, endpoint, workflow or human process?
- Evidence boundary. Which observations must be preserved to show what was decided, executed and observed, and whether the system still matches the conditions under which it was approved?
These boundaries often overlap, but they should not be forced to coincide. That distinction is what makes supplier dependencies, human approvals and cross-system actions governable without pretending they all live inside one technical perimeter.
What authoritative sources establish
NIST AI RMF treats AI risk management as a lifecycle activity and its MAP function emphasizes context, intended purposes, stakeholders, impacts and dependencies. This supports defining the system in context before control selection. It does not prescribe the six-boundary model above.
ISO/IEC 42001:2023 establishes an organizational AI management system and requires organizations to determine relevant context, roles, processes and continual improvement. It supports explicit scope and governance interfaces, but it is not a technical system-boundary blueprint.
OECD AI Principles and lifecycle work recognize that AI systems involve multiple actors across their lifecycle. This is useful for responsibility and value-chain reasoning, while remaining non-binding policy guidance rather than a legal allocation of responsibility.
The EU AI Act distinguishes roles such as provider, deployer, importer and distributor and contains value-chain responsibilities, including Article 25. Those legal role boundaries matter where the Regulation applies. They should not be generalized into a universal architecture for systems outside scope.
Boundary first, then implementation
If architecture starts with products, responsibility tends to follow the product diagram. That produces familiar mistakes: the model provider is treated as the system boundary, the cloud account as the security boundary, the workflow engine as the authority model and the logging platform as the evidence model.
Those tools may implement parts of the architecture, but they should not define it by accident. The boundary should be stable enough that a model, framework or provider can be replaced without changing who owns the use case, who accepts risk, which actions require approval or what evidence is needed to prove the approved system is still the deployed system.
A useful falsification test is simple: if replacing a supplier changes the definition of responsibility, authority or required evidence, the architecture was probably describing the supplier rather than the governed system.
Interface to strategy and portfolio
The purpose boundary connects directly to L1 Strategy & Portfolio. A use case should enter the portfolio with a defined outcome, accountable owner, material dependencies and evidence expectations. Otherwise, technical teams are asked to qualify a system whose business boundary is still undefined.
This also gives portfolio governance a practical stop condition. If the organization cannot state what outcome is being pursued and which entity owns the decision, it is too early to treat the initiative as an implementation problem.
Interface to enterprise risk and decision governance
The responsibility and authority boundaries connect to Enterprise Risk & Decision Governance. Risk acceptance, material exceptions, legal applicability and changes to organizational appetite are management decisions. They should not be silently encoded into prompts, workflow defaults or product settings.
The architecture therefore preserves a decision chain from business objective through accountable owner, risk decision and approved conditions to execution and observed effect. Technical controls implement parts of that chain; they do not own the enterprise decision.
Three practical boundary cases
1. External model, internal decision
A model hosted by a supplier is outside the organization's infrastructure boundary, but it can still be inside the governed AI system if its outputs materially influence an internal decision. The supplier relationship, data exchange and model behavior remain relevant dependencies even when execution occurs elsewhere.
2. Human approval, external workflow
A human reviewer may approve an action through email, a ticketing system or another application. That person is outside the agent runtime but inside the authority boundary. Treating the human as “outside the system” would remove a material control and its evidence from the architecture.
3. Tool call, downstream effect
An agent may invoke a tool that changes a record in another business system. The tool interface may be only one API call, but the relevant execution boundary includes the downstream state transition and the evidence required to confirm the intended effect. The governance question is about the consequential action, not the transport protocol.
A boundary checklist
Before selecting a framework or platform, ask:
- What business purpose defines the system?
- Which legal entity and accountable owner are responsible for the use case?
- Which suppliers and external systems are material dependencies?
- Which data crosses organizational, jurisdictional or trust boundaries?
- Who can authorize consequential actions and exceptions?
- Where do actions produce real-world or business-system effects?
- Which evidence is needed to reconstruct the decision and verify the effect?
- Which change would make the previous approval stale?
If the answers are explicit, tool selection becomes a mapping problem. If they are not, tool selection is being asked to solve an architecture problem it cannot solve.
Claim status
- Established: authoritative sources support lifecycle risk management, organizational scope, context, actor roles and continual reassessment.
- Architecture synthesis: separating the governed boundary into purpose, responsibility, data, authority, execution and evidence views.
- Design principle: the governed boundary should remain meaningful when replaceable products and providers change.
- Not claimed: that the six views are required by NIST, ISO, OECD or EU law, or that every organization must implement them identically.
Next in the series
With the L0 vision and boundary defined, the series moves next to L1 Strategy & Portfolio: From AI Use Cases to a Governed Portfolio. The question becomes which initiatives deserve investment, ownership and progression—and which should stop before they become production commitments.