A practical reading path
Enterprise AI Architecture & Governance
A practical reading path for designing enterprise AI around identity, tool permissions, knowledge boundaries, evaluation and operational ownership.
An enterprise AI system has more than a model and a prompt. It has identities, access to business information, tools that can change records, people who approve exceptions, and a team responsible when recovery fails. Start with those boundaries before choosing an orchestration framework.
This guide connects the architecture decisions to the operating controls. Follow the sequence for a new platform, or use the decision table to investigate a specific problem.
Start with authority and ownership
Read AI Governance Architecture: Identity, Trust, Permission, and Ownership first. Use it to separate who an agent represents, what it may access, which actions it can perform, and who owns the consequences.
Then work through the AI ownership model. A useful output is a short record naming the owners of the workflow, model deployment, source collections, tool actions and escalation path. A generic “AI team” label does not resolve those responsibilities.
For the wider organizational view, the CIO target operating model connects platform responsibilities, delivery teams and operational controls.
Design the boundaries that survive deployment
| Architecture question | Read next | Bring back to your design review |
|---|---|---|
| Which identity does each action use? | Zero Trust for Enterprise AI Agents | A map of delegated identities and least-privilege scopes. |
| What does invoking a tool actually authorize? | Tool Contracts for Enterprise AI Agents | A contract covering authority, retries, idempotency and evidence. |
| Which source can answer which question? | RAG Governance | A source-authority map with access and freshness rules. |
| Does deleting a source remove its derivatives? | RAG Deletion | A dependency manifest and tests for caches, memory and reintroduction. |
| Can a fallback model process the same information? | Model Failover for Enterprise AI | Eligible routes and explicit workflow recovery checkpoints. |
These artifacts describe different controls. A correct function schema does not prove authorization, and a model gateway does not prove that the next provider is permitted to receive a document.
Run the Enterprise AI Tool Contract Lab to exercise a small offline example: permission denial, approval binding and expiration, concurrent duplicate requests, and structured audit decisions. The download includes the Python example, contract and executable checks.
Make release and recovery observable
Use eval gates for enterprise AI workflows to define the behavior that must hold before a workflow is released. Include access-boundary and tool-action cases alongside answer quality. Keep the test evidence tied to the deployed configuration.
Audit logs for enterprise AI agents explains how to retain enough context to reconstruct an action. Connect that evidence to AI incident response, so the team can contain a failing workflow and establish what it affected.
Two operational limits deserve explicit treatment: human review capacity and agent cost budgets. The first constrains work against the people who must review it; the second reserves spend before concurrent requests start. Both belong in admission control, before a queue or bill becomes the only signal.
Use this guide for a platform review
Choose one real workflow and trace a document from ingestion to a business action. Record its identity, authorized sources, allowed tools, approval rule, recovery checkpoint and evidence trail. For each boundary, ask what observable test would show that a prohibited path is blocked.
The review is useful when it produces owners, enforceable rules and repeatable checks. Keep unresolved assumptions in the record rather than hiding them behind a successful demo.
When the workflow reaches a physical system
An enterprise permission to request a task does not establish that a robot can safely execute it. Continue with Robotics Architecture & Safety for command validation, timing and control boundaries. For deployment on embedded compute, use Jetson & ROS 2 Engineering.