--- title: "AI system architecture and controls | YPAI" url: https://ypai.ai/ai-implementation/discovery-and-architecture/architecture/ description: "How YPAI defines an AI system: eleven operating layers, the least complex pattern that passes acceptance, and the security, failure and governance controls." source: "src/copy/routes (route /ai-implementation/discovery-and-architecture/architecture/)" --- # The model is one component. > How YPAI defines an AI system: eleven operating layers, the least complex pattern that passes acceptance, and the security, failure and governance controls. How YPAI defines the system: eleven operating layers, one authority boundary and the least complex pattern that passes the acceptance test. - A model can generate text, classify an input, extract information or propose a next step. - A production system must also control identity, context, permissions, actions, exceptions, evidence and failure. - YPAI makes eleven operating layers explicit. ## Start with the work, not the model. - The first question is not which model to buy. - It is what outcome the system must produce, what information it may use, what actions it may take, who retains authority and what must happen when it is wrong. - YPAI studies the workflow as it operates today. We identify where deterministic software is sufficient, where AI adds measurable value, where human judgement remains necessary and where the operational risk outweighs the expected return. - The result is a defined system with an intended purpose, an operating boundary and a measurable path to production. ## Eleven layers, eleven recorded decisions - Where the system appears and how users interact with it. - Who the user is, what they may see and which actions they may initiate. - How work progresses, pauses, resumes, branches, expires and recovers. - Which model or model class handles each task, including fallback, routing and version control. - What information enters the context, where it comes from, how long it persists and when it is refreshed. - Which APIs, databases, applications, queues and external services the system may use. - Where data is processed, stored, transformed, logged and deleted. - What must be blocked, validated, filtered or routed for additional review. - Which decisions require approval, which failures trigger escalation and who can override the system. - How quality, behaviour, cost, latency, failures and regressions are measured. - How the system is released, monitored, updated, rolled back and maintained. The selected model is recorded inside this structure. It is not treated as the architecture by itself. ## Authority boundaries - The architecture separates the ability to recommend an action from the authority to execute it. That boundary is explicit, testable and reviewable. - It is recorded as what the system may retrieve, recommend, generate, decide, execute, approve, escalate or never perform autonomously. ## Use the least complex system that can pass the acceptance test. - Some workflows need deterministic automation with one model-assisted step. - Some need retrieval over controlled knowledge. - Some need an assistant that recommends an action but cannot execute it. - Some need a tool-using agent with bounded authority, approval gates and recovery paths. - Some need a predictive model, document pipeline, voice interface or multimodal system inside an otherwise conventional application. YPAI compares the available patterns against the actual requirement. The decision is based on quality, controllability, latency, data sensitivity, integration depth, volume, failure consequence, portability, cost and operating burden. Complexity and autonomy are added only when they improve the accepted outcome. ## Compare the complete system, not isolated model benchmarks. - cloud, private cloud, on-premises and hybrid deployment - existing enterprise software instead of a custom build - The recommended architecture must explain why each component exists, what requirement it satisfies and what would justify replacing it. - A more sophisticated component is not automatically a better component. ## Architecture begins with the information the system can trust. - YPAI examines the data and knowledge required to perform the workflow. - This includes, as far as the workflow needs them: - The output distinguishes between data that exists, data that is technically accessible, data that may lawfully be used and data that is fit for the intended task. - Where the required material is missing, YPAI can define the collection, annotation, curation or evaluation work needed before implementation continues. ## An integration is also a permission to act. - Connecting an AI system to a CRM, ERP, HRMS, document repository, messaging platform or operational database changes what the system can see and what it can do. - For each integration, YPAI defines the items that apply: ## Design for the failure, not only the successful path. - The discovery process examines how the system can fail through incorrect output, missing context, manipulated input, excessive authority, compromised tools, data exposure, unavailable dependencies or uncontrolled cost. - The architecture draws its controls from this list, chosen per risk: - Controls are assigned to specific risks and failure modes. They are not added as a generic security layer after the system has already been designed. ## Governance is part of the architecture. - Where an AI system can affect people, money, access, safety, employment, eligibility, regulated activity or material business decisions, its intended purpose and operating authority must be explicit. - Where the system requires it, the discovery record can define: - The architecture and control records can follow the structure of applicable EU AI Act requirements and recognised frameworks such as NIST AI RMF, ISO/IEC 42001, ISO/IEC 23894, ISO/IEC 42005 and the ISO/IEC 5259 data-quality series. - These records give your organisation the technical and operational evidence it needs to operate the system. ## Frequently asked questions ### Do we need to select a model or cloud provider first? Model, platform and deployment choices are architecture outputs. YPAI compares the viable options against the workflow, data, controls, performance requirements and economics. ### Can discovery cover regulated or sensitive workflows? Yes. The scope can include intended-purpose analysis, impact and risk inputs, data boundaries, human oversight, logging, documentation, deployment controls and applicable regulatory requirements. ### Does YPAI recommend agents for every automation use case? YPAI selects the least complex architecture that can meet the acceptance criteria. That may be deterministic automation, a constrained assistant, RAG, a model-assisted workflow, a tool-using agent or an existing enterprise product.