The 3-Layer Architecture Review: Correct Before Compliant

There is an ordering problem that kills AI deployments in the first sixty days. Organizations spend six months getting the system compliant — SOC 2 reports, DPAs signed, legal clearance issued — and then discover post-launch that the architecture itself is wrong. The system answers questions it should not be able to answer. The retrieval layer returns data across tenant boundaries. The caching layer stores sensitive outputs that should never be persisted. Compliance with a broken architecture is not a safety net. It is a liability that has been dressed in paperwork.

The 3-layer architecture review runs before compliance review for exactly this reason. Layer one is the data layer — where data lives, how it moves, what boundaries exist, and whether the system can enforce those boundaries under load. Layer two is the application layer — where business logic executes, where model calls are made, and where output handling occurs. Layer three is the integration layer — every external dependency, every API surface, every point where the system touches something it does not own. Review all three layers for correctness first. Then review for compliance.

1. Layer 1: Data Layer Review Map every data store in the system — databases, vector stores, caches, message queues, file systems. For each store, document: what data it holds, the sensitivity classification, the access controls, the encryption state at rest and in transit, and the tenant isolation mechanism if the system is multi-tenant. Identify every path by which data can leave a store — query interfaces, export functions, backup processes, logging pipelines. A data store with correct access controls and a logging pipeline that writes unredacted outputs to a shared log is not isolated. The log is the vulnerability.
2. Layer 2: Application Layer Review Review every point where business logic makes a model call. Document the system prompt content, the user input handling, the output post-processing, and the error handling. For each model call, answer: what is the maximum scope of information this call could return? What happens when the model returns an unexpected output format? What happens when the model returns a refusal? Application logic that fails open — defaulting to action when the model returns an error — is a critical finding. Applications must fail safely by design.
3. Layer 3: Integration Layer Review Map every external dependency — APIs, databases, identity providers, monitoring services, third-party enrichment services. For each dependency, document: the authentication mechanism, the authorization scope granted, the data sent in requests, the data received in responses, and the behavior when the dependency is unavailable. Over-permissioned API keys are the most common integration layer finding. A model that can query your CRM API with admin credentials because no one scoped the key correctly is not an AI risk — it is an access control failure that the AI surface area exposed.