Why does yeshcube design its AI-based products as AI-native?
AI-native is an architectural principle under which artificial intelligence capabilities, the data that supports them and the mechanisms used to evaluate them are defined from the start of a system. At yeshcube, the term describes an internal design decision for solutions whose core function depends on algorithmic models.
The principle brings technical, scientific and governance requirements into the same lifecycle. Efficacy, safety, regulatory compliance and positive impact require separate evidence and controls.
Scope of the AI-native concept
The term AI-native is used with different nuances across industries. In telecommunications, Ericsson defines it as the integration of trustworthy AI capabilities into system design, deployment, operation and maintenance.
yeshcube uses an operational definition consistent with that approach. A solution is considered AI-native when its core function depends on AI capabilities planned from the requirements stage, together with their data, limitations, metrics and oversight mechanisms.
The category describes architecture. An AI-enabled system adds an AI capability to existing infrastructure. An AI-native system is structured around that capability from the outset.
| Aspect | AI-enabled | AI-native |
|---|---|---|
| Starting point | An AI capability is added to an existing system | The system is defined around an AI capability from the outset |
| Functional dependency | AI extends an existing function | The AI capability is central to the intended function |
| Evaluation | Evaluation is adapted to an existing architecture | Evaluation is defined alongside requirements and risks |
| Governance | Governance is incorporated into pre-existing processes | Governance is part of the planned system lifecycle |
The distinction is descriptive. The appropriate architecture depends on purpose, context of use, risk level and whether AI is genuinely needed.
Requirements at system definition
An AI-native architecture requires several questions to be answered before models or interfaces are selected. The problem, target population or context, supported decisions and consequences of an incorrect response must be specified.
Functional boundaries also need to be established. These include tasks the system may perform, tasks requiring human intervention, withdrawal conditions and behaviors outside the intended scope.
Evaluation is designed in parallel. Technical metrics, utility criteria, foreseeable risks and validation conditions should correspond to the intended use. An isolated accuracy score is insufficient when a system affects people, sensitive processes or decisions with material consequences.
Data, models and traceability
AI-native design treats data as part of the architecture. Its origin, legal basis where personal data is involved, transformations, quality criteria, limitations and potential biases should be documented.
Traceability also covers models and system configuration. Depending on the case, this may include model versions, instructions, available tools, parameters, evaluation sets, behavioral changes and incident records.
The NIST AI Risk Management Framework organizes risk management through the functions Govern, Map, Measure and Manage. It treats risk management as a continuous lifecycle activity and provides a useful reference for structuring responsibilities and controls, although its use is voluntary.
Documentation allows reviewers to reconstruct which system acted, under which configuration, with what information and under which oversight rules. Explainability requires additional methods suited to the model and intended use.
Modular architecture and interoperability
Components within an AI-native solution can be separated to reduce coupling and support evaluation. The model, context sources, tools, access policies and interface may evolve at different rates when their contracts are clearly defined.
Model Context Protocol is one example of a protocol for exchanging context and exposing tools through a client-server architecture. The official MCP architecture documentation describes capability discovery, resources, tools and transport mechanisms.
MCP may support interoperability in some systems. Authorization, privacy, tool security and action control require specific measures. Each integration needs access restrictions, input and output validation, credential management, activity logging and review of the resulting attack surface.
yeshcube treats protocols of this kind as architectural options to be assessed for each solution. MCP implementation must be confirmed in the documentation for each product or project.
Application within the Somia architecture
Somia is a yeshcube artificial intelligence architecture that can be integrated into first-party or third-party products and solutions. The AI-native principle requires each integration to define the purpose of the AI, necessary data, operating boundaries and evaluation mechanisms from the outset.
A specific integration may use conversation, audio, context or other modalities where these are documented for that product. Emotional detection, personalization, autonomy and real-time adaptation must be confirmed in product-specific documentation.
Somia Within identifies integrations of Somia into third-party solutions. The technical scope and assurances of each integration should be stated in its own documentation. Efficacy requires assessments suited to the use case.
Scientific evaluation and the ERL scale
AI-native design allows evaluation questions to be formulated before deployment. This can improve alignment between hypotheses, data, metrics and architecture. Favorable outcomes remain an empirical question.
The ERL scale is used at yeshcube to organize evidence readiness. A solution’s level should only be stated when a documented assessment exists. AI-native architecture, as a design principle, holds no level of its own; the level of each specific solution or integration corresponds to its documented assessment.
Evaluation for systems with human impact may cover several dimensions:
- Technical performance under defined conditions.
- Robustness to errors, distribution shifts and adversarial inputs.
- Data quality and representativeness.
- Utility for the intended objective.
- Risks to privacy, security and rights.
- Capacity for oversight, correction and withdrawal.
- Outcomes observed in the evaluated population and context.
Results should identify the source, population, context, method and limitations. A functional prototype, collaboration, selection or award documents that event. Efficacy, safety and scientific maturity require specific evidence.
Governance and accountability
An AI-native architecture requires assigned responsibilities throughout development and operation. It should be clear who approves requirements, who may modify the system, who reviews incidents and who can suspend it.
Decision records can document choices involving data, models, providers, metrics and accepted risks. Change controls help determine when a modification requires repeated testing or a review of the intended use.
Human oversight must be designed for the specific task. Its formal presence is insufficient when the responsible person lacks information, time, authority or practical means to intervene.
Privacy by design
When a solution processes personal data, AI-native design must be coordinated with the General Data Protection Regulation. Article 25 of the GDPR requires technical and organizational measures to be integrated when processing means are determined and requires data minimisation by default.
A data protection impact assessment may be mandatory when processing is likely to create a high risk to people’s rights and freedoms. The planned processing determines this requirement. The AI-native label has no legal bearing on it.
Anonymisation, encryption and access controls are possible safeguards within an AI-native architecture. Their use depends on the confirmed implementation of each yeshcube solution.
Relationship with the European Union AI Act
The European Union AI Act follows a risk-based approach. Intended purpose and context of use determine the regulatory classification.
For systems classified as high-risk, the Regulation sets requirements covering risk management, data governance, technical documentation, record-keeping, transparency, human oversight, accuracy, robustness and cybersecurity. Some transparency obligations also apply to certain systems that interact with people.
Designing these elements from the outset may reduce later incompatibilities. Compliance must still be assessed for each system, function and deployment, together with any sector-specific legislation that applies.
Risks and limitations
Structural dependence on AI can increase the impact of model failures, unsuitable data, provider changes or performance degradation. It can also expand the attack surface when the system accesses tools, external sources or automated actions.
Further risks include opacity, excessive automation, bias, unnecessary data extraction and difficulty reproducing outcomes. Controls should be proportionate to potential harm and the system’s degree of autonomy.
AI-native design requires contingency strategies. These may include capability restrictions, human oversight, testing before changes, monitoring, version rollback and temporary withdrawal. Their presence must be verified in the documentation for each solution.
yeshcube’s architectural criterion
yeshcube applies AI-native to coordinate architecture, evidence and governance from the definition of a solution that incorporates artificial intelligence. The principle provides a basis for requirements and responsibilities before models are integrated into a product or service, and it does not extend to developments in which AI plays no part.
Its value depends on implementation. System quality must be demonstrated through documentation, evaluation, monitoring and controls suited to the context. AI-native functions as a design criterion. Outcomes require validation.
References
Related content
Other products
