Executive Summary
This architecture review turns an AI product design into a set of reviewable security boundaries. It covers the model boundary, retrieval boundary, tool boundary, approval boundary, trace boundary, provider boundary, and release boundary. The review does not ask whether the system “uses AI responsibly.” It asks the questions that matter before launch: what data moves, where authority expands, what can act, what is approved, what is logged, and what proof exists.
Architecture review decision
Proceed with constrained pilot use, but do not expand retrieval sources, tool authority, or enterprise claims until the retrieval boundary, tool boundary, and provider boundary have stronger evidence.
Architecture Review Snapshot
Architecture review is where AI risk becomes concrete
System in scope
| Field | Value |
|---|---|
| System | Northstar Support Cloud / Customer Support Copilot |
| Status | Production pilot |
| Risk tier | Tier 4: agentic or state-changing |
| Business owner | VP Product |
| Technical owner | AI Platform Engineering |
| Security owner | Product Security |
| Primary use case | retrieve support context, draft responses, prepare workflow actions |
Architecture Boundary Review
The architecture review maps the major AI product boundaries and identifies where implementation evidence is still partial.
Architecture boundary review
| Boundary | Risk | Owner | Status | Evidence |
|---|---|---|---|---|
| Model boundary | High | AI Platform Engineering | Partial | model-provider-boundary-statement |
| Retrieval boundary | Critical | Search Platform | Partial | rag-authorization-review |
| Tool boundary | Critical | AI Platform Engineering | Partial | agent-tool-inventory |
| Approval boundary | High | Product Operations | Partial | approval-context-bundle |
| Trace boundary | High | Security Engineering | Partial | ai-trace-schema |
| Release boundary | High | Product Security | Planned | ai-release-gate-checklist |
Architecture Findings
Retrieval boundary is designed but not proven
The architecture relies on authorization-preserving retrieval, but evidence does not yet prove the full path from source ACL to generated answer.
Impact
Tool boundary needs action-class enforcement
Tool access is not fully enforced as distinct action classes. This makes blast radius and approval requirements harder to reason about.
Provider boundary is not ready for enterprise review
Provider route, training-use, retention, subprocessors, and data minimization need buyer-ready language tied to evidence.
Trace boundary has a sensitive evidence policy gap
AI traces are useful for audit and incident response, but they can also become a sensitive data store without retention and access controls.
Architecture review questions
| Boundary | Question | Status |
|---|---|---|
| Model | Are all model calls routed through the AI gateway? | Partial |
| Retrieval | Does authorization survive indexing, chunking, reranking, and prompt assembly? | Partial |
| Tool | Are actions separated by read, suggest, draft, queue, approve, and execute? | Partial |
| Approval | Can a reviewer make a meaningful approval decision? | Partial |
| Trace | Can AI behavior be reconstructed after an incident? | Partial |
Companion artifacts needed for a complete review
Launch readiness decision
Launch readiness should depend on boundary evidence, not architecture confidence. Retrieval, tool, provider, trace, and release boundaries all need a named owner and evidence before expansion.
Related artifact: AI Trust Boundary Map
The trust boundary map is the diagrammatic companion to this architecture review.
Related artifact: RAG Authorization Review
The RAG authorization review deepens the retrieval boundary evidence.
Related artifact: Agent Tool Inventory
The tool inventory deepens the tool boundary evidence.