AI Implementation / Discovery and Architecture / Architecture
The model is one component.
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.
Architecture and controls
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 model decision comes later.
The result is not an AI concept or a generic transformation roadmap. It is a defined system with an intended purpose, an operating boundary and a measurable path to production.
Eleven layers, eleven recorded decisions
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.
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.
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.
Some do not need AI.
Compare the complete system, not isolated model benchmarks.
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.
YPAI can evaluate combinations of:
- deterministic workflow automation
- hosted foundation models
- managed enterprise AI platforms
- open-weight and self-hosted models
- model routing and gateway layers
- retrieval-augmented generation
- structured knowledge and graph retrieval
- document extraction and classification
- tool-using agents
- single-agent and orchestrated workflows
- human review and approval stages
- voice and multimodal interfaces
- cloud, private cloud, on-premises and hybrid deployment
- existing enterprise software instead of a custom build
Architecture begins with the information the system can trust.
YPAI examines the data and knowledge required to perform the workflow.
This includes:
- authoritative source systems
- document and record ownership
- access permissions
- data contracts and schemas
- format and structural consistency
- historical coverage
- language and market coverage
- update frequency
- version history
- retention and deletion requirements
- personal and sensitive data
- rights and permitted use
- retrieval and indexing requirements
- annotation or evaluation gaps
- ground-truth availability
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.
YPAI defines:
- read and write permissions
- user and service identities
- authentication and authorisation
- tool schemas
- action limits
- transaction boundaries
- idempotency
- validation rules
- approval requirements
- rate limits
- retries and timeouts
- audit events
- rollback and compensation behaviour
- degraded-mode operation
The architecture separates the ability to recommend an action from the authority to execute it. That boundary is explicit, testable and reviewable.
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 can include:
- prompt-injection and indirect-injection controls
- least-privilege tool access
- allowlisted actions and destinations
- input and output validation
- schema-constrained generation
- sandboxed execution
- secrets isolation
- network and data boundaries
- rate and budget limits
- human approval
- anomaly detection
- kill switches
- fallback workflows
- rollback paths
- incident logging and replay
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.
The discovery record can define:
- intended purpose
- users and affected parties
- provider and deployer responsibilities
- risk classification
- impact assessment inputs
- human oversight
- logging requirements
- technical documentation requirements
- model and data provenance
- quality and testing evidence
- change and version control
- post-deployment monitoring
- incident and corrective-action procedures
The architecture and control records can be structured against 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.
The purpose is not to add a compliance label to the page.
The purpose is to create the technical and operational evidence the organisation will need to operate the system.
Discovery and architecture
Frequently asked questions
Do we need to select a model or cloud provider first?
No. 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?
No. 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.