The Etheon Enterprise AI Architecture Report 2026

Executive Summary

Enterprise AI has moved beyond experimentation. In 2026, the central challenge is not whether organizations can access AI models. The challenge is whether they can design enterprise AI architecture that turns models, data, workflows, governance, and human oversight into production systems the business can trust.

This is the year enterprise AI becomes an architecture discipline.

AI adoption is already broad. McKinsey’s 2025 global AI survey found that 88% of organizations reported regular AI use in at least one business function, up from 78% the year before, while most organizations still had not scaled AI to enterprise-wide impact [1]. Deloitte’s 2026 enterprise AI research found that worker access to AI rose by 50% in 2025 and that companies expect production AI scale to accelerate [2]. Stanford HAI’s 2026 AI Index reports that AI capabilities continue to advance quickly, while responsible AI measurement and incident tracking remain behind the pace of deployment; documented AI incidents rose to 362 in 2025, up from 233 in 2024 [3]. Gartner has warned that more than 40% of agentic AI projects may be canceled by the end of 2027 because of escalating costs, unclear business value, or inadequate risk controls [4].

Those signals define the 2026 architecture problem: enterprises are using AI, but many are not yet architecting AI as durable operating infrastructure.

The Etheon Enterprise AI Architecture Report 2026 presents a practical architecture framework for decision-stage leaders. It explains how to design enterprise AI systems that are not just impressive in prototypes, but secure, governed, measurable, maintainable, and ready for production workflows.

The core finding is simple:

Enterprise AI architecture in 2026 must be designed around systems, not models.

Models matter. But production AI value comes from the full system around the model: business objectives, data foundations, identity, retrieval, tool access, evaluation, guardrails, observability, governance, support, and continuous improvement.

Research and Market Audit: The Shift From AI Adoption to AI Architecture

The enterprise AI market has entered a new phase. From 2023 to 2025, many organizations focused on access: copilots, chatbots, pilots, proof-of-concepts, prompt experiments, and AI productivity tools. In 2026, the discussion is shifting to production architecture.

Three facts define this shift.

First, AI use is now mainstream, but scaling remains uneven. McKinsey reports that 88% of organizations use AI in at least one business function, yet most have not scaled AI to enterprise-wide impact [1]. That means AI adoption is not the same as AI maturity.

Second, production expectations are rising. Deloitte’s 2026 enterprise AI report states that worker access to AI increased by 50% in 2025 and that the number of companies with at least 40% of AI projects in production is expected to double within six months [2]. This means more AI systems are moving into real operations, where architecture, support, and governance matter.

Third, AI risk is becoming more visible. Stanford HAI reports that documented AI incidents increased from 233 in 2024 to 362 in 2025, while responsible AI benchmarking remains inconsistent [3]. Gartner’s forecast that over 40% of agentic AI projects may be canceled by the end of 2027 reinforces the same point: AI failure is often not a model-capability problem; it is an architecture, governance, value, and risk-control problem [4].

The conclusion for enterprise buyers is clear: the next stage of AI competition will be architectural. Companies will differentiate not by having access to the same frontier models, but by how well they connect those models to proprietary data, workflows, governance, and operating discipline.

The 2026 Definition of Enterprise AI Architecture

Enterprise AI architecture is the structured design of the systems, data, models, applications, workflows, controls, and operating practices that allow AI to create business value safely at scale.

It includes:

- Business and product architecture.

- Data and knowledge architecture.

- Model and inference architecture.

- Retrieval and grounding architecture.

- Agent and tool architecture.

- Identity and access architecture.

- Security and privacy architecture.

- Evaluation and observability architecture.

- Governance and compliance architecture.

- Deployment and maintenance architecture.

This is why AI architecture cannot be reduced to “which model should we use?” Model selection is one decision inside a larger system. A high-quality model can still fail if retrieval is wrong, permissions are weak, data is stale, tool access is too broad, evaluation is missing, or users do not trust the workflow.

AWS’s Well-Architected Generative AI Lens states that generative AI workloads require guidance across design, deployment, operation, and Well-Architected pillars such as operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability [13]. Google Cloud’s MLOps guidance describes ML operations as a culture and practice that unifies ML development and operations, advocating automation and monitoring across integration, testing, release, deployment, and infrastructure management [14]. OpenAI’s production guidance similarly focuses on moving AI projects from prototype to production with attention to scaling, security, cost management, and robust architecture [15].

The implication is direct: enterprise AI systems should be designed as lifecycle-managed production systems.

Key Findings From the Etheon 2026 Architecture View

Finding 1: The winning architecture is workflow-centered, not model-centered

Enterprises should not begin with “What model should we deploy?” They should begin with “Which workflow should change, what data does it need, what decisions are made, what actions are allowed, and how will value be measured?”

Finding 2: Secure RAG is becoming core enterprise infrastructure

Retrieval-augmented generation is no longer a side feature. For many enterprises, it is the knowledge layer that connects AI to internal policies, procedures, contracts, tickets, product documentation, and customer records. But it must be permission-aware, source-ranked, monitored, and evaluated.

Finding 3: AI agents require a control plane

Agentic AI adds planning and tool use, but also increases risk. Agents need identities, tool allowlists, approval gates, audit logs, execution boundaries, and kill switches. Autonomy without architecture becomes operational risk.

Finding 4: Evaluation is becoming a permanent system layer

AI evaluation is not a one-time launch test. OpenAI notes that generative AI variability makes traditional testing insufficient by itself; evaluations are required to test AI systems despite variability [16]. In 2026, evaluation must become continuous and connected to production monitoring.

Finding 5: Governance is becoming architecture

NIST’s AI Risk Management Framework helps organizations manage risks to individuals, organizations, and society associated with AI [5]. ISO/IEC 42001 provides a structured management-system approach for organizations that develop, provide, or use AI systems [6]. The EU AI Act becomes broadly applicable from August 2, 2026 with phased exceptions and requirements [7]. These frameworks show that governance is not paperwork after deployment; it is a design layer inside enterprise AI architecture.

The Etheon Enterprise AI Architecture Model

The Etheon model organizes enterprise AI architecture into 12 layers. These layers are not optional for production systems. Some can be lightweight for low-risk systems, but each must be considered.

1. Architecture layer: Business architecture

Purpose: Defines business outcomes, workflows, owners, KPIs, and ROI

2. Architecture layer: User experience architecture

Purpose: Defines how humans interact with AI and review outputs

3. Architecture layer: Data architecture

Purpose: Defines sources, classification, lineage, freshness, and ownership

4. Architecture layer: Knowledge and retrieval architecture

Purpose: Grounds AI in enterprise knowledge through secure retrieval

5. Architecture layer: Model architecture

Purpose: Selects models, routing, hosting, inference, and lifecycle policies

6. Architecture layer: Agent and tool architecture

Purpose: Controls tool use, APIs, workflows, and agent actions

7. Architecture layer: Identity and access architecture

Purpose: Enforces user, agent, service, and data permissions

8. Architecture layer: Security and privacy architecture

Purpose: Prevents prompt injection, data leakage, misuse, and supply-chain risk

9. Architecture layer: Evaluation architecture

Purpose: Tests quality, safety, retrieval, grounding, and tool behavior

10. Architecture layer: Observability architecture

Purpose: Tracks prompts, retrievals, tool calls, costs, failures, and feedback

11. Architecture layer: Governance architecture

Purpose: Manages risk tiers, approvals, documentation, and accountability

12. Architecture layer: Operations architecture

Purpose: Maintains AI systems after launch through LLMOps, MLOps, and support

A production-ready AI system should be reviewed against all 12 layers before scaling.

Layer 1: Business Architecture

Business architecture defines why the AI system exists.

A strong enterprise AI architecture begins with:

- Business objective.

- Workflow owner.

- Target users.

- Current baseline.

- Target KPI.

- Risk tier.

- Cost model.

- Human role.

- Production success criteria.

- Retirement criteria.

This layer protects the organization from AI projects that are technically interesting but commercially vague. Gartner’s warning about canceled agentic AI projects is tied directly to unclear business value, rising cost, and inadequate risk controls [4]. Enterprise AI architecture must therefore begin with value discipline.

A weak business architecture says, “We need an AI agent.”

A strong business architecture says, “We need a human-reviewed billing-ticket triage agent that reduces average triage time by 30%, retrieves only approved customer and policy data, drafts recommendations for support specialists, and escalates refund or contract exceptions to managers.”

The second statement can be architected.

Layer 2: User Experience Architecture

Enterprise AI is only useful if humans can use it correctly.

User experience architecture defines:

- Where the AI lives.

- What users ask or submit.

- What the AI returns.

- What evidence is shown.

- What actions are available.

- When the user must approve.

- How users correct the AI.

- How feedback is captured.

- What limitations are disclosed.

- How trust is built.

This layer is especially important because AI can produce persuasive outputs that may be wrong or incomplete. A good interface should not simply show an answer. It should show sources, assumptions, confidence indicators where appropriate, next steps, and escalation paths.

For high-risk workflows, user experience architecture must make human oversight meaningful. Reviewers need context, authority, and enough information to approve, reject, edit, or escalate.

Layer 3: Data Architecture

Data architecture is the foundation of enterprise AI systems. AI systems cannot be trusted if the data is not governed.

A production-ready AI data architecture defines:

- Source systems.

- Source owners.

- Data classification.

- Data lineage.

- Freshness requirements.

- Retention rules.

- Deletion rules.

- Access controls.

- Data residency.

- Sensitive data handling.

- Evaluation datasets.

- Data quality thresholds.

CISA’s 2025 AI data security guidance emphasizes that data security is critical to the accuracy, integrity, and trustworthiness of AI outcomes and highlights practices such as securing data provenance, storage, and supply chains [17].

For enterprise AI systems, data architecture must answer: Can the AI use the data? Should the AI use the data? Is the data current? Is the user allowed to see it? Can the output be traced back to it?

If not, the system is not production-ready.

Layer 4: Knowledge and Retrieval Architecture

For many enterprise AI systems, retrieval architecture is the difference between generic AI and enterprise AI.

A secure retrieval layer should include:

- Approved data sources.

- Secure ingestion.

- Metadata preservation.

- Permission-aware indexing.

- Hybrid search where needed.

- Semantic ranking.

- Source authority scoring.

- Citation generation.

- Freshness checks.

- Deletion propagation.

- Retrieval evaluation.

- Vector index security.

OWASP identifies vector and embedding weaknesses as a major LLM application risk, including unauthorized access and data leakage through embedding and retrieval systems [8]. This matters because enterprise RAG systems often contain sensitive internal information.

A production RAG architecture must enforce permissions before content enters the model context. It should not retrieve restricted content and then rely on the model to avoid revealing it. Authorization belongs outside the model.

Layer 5: Model Architecture

Model architecture determines which models are used, how they are hosted, when they are routed, and how they are replaced.

In 2026, enterprises should avoid one-model-fits-all architecture. Some workflows need frontier models. Some need small language models. Some need open-weight models. Some need private deployment. Some need classical machine learning. Some need deterministic rules.

Model architecture should define:

- Model selection criteria.

- Model provider or hosting environment.

- Model routing rules.

- Context window strategy.

- Cost controls.

- Latency targets.

- Fallback models.

- Versioning.

- Deprecation monitoring.

- Evaluation before model changes.

- Data-use and retention review.

OpenAI’s production guidance emphasizes robust architecture, security, and cost management when moving AI applications to production [15]. Its model and production documentation also reflects a world where models evolve and applications need lifecycle planning. Enterprise systems should therefore abstract model dependencies where practical, so a model update does not require rebuilding the whole application.

Layer 6: Agent and Tool Architecture

Agent and tool architecture defines what AI can do.

An AI agent may retrieve data, call APIs, create tickets, update records, generate reports, query databases, send notifications, or trigger workflows. This makes tool architecture one of the highest-risk layers.

A secure agent architecture requires:

- Dedicated agent identity.

- Tool allowlists.

- Typed schemas.

- Tool input validation.

- Tool output validation.

- Least-privilege access.

- Human approval gates.

- Rate limits.

- Execution logs.

- Rollback or compensating actions.

- Kill switch.

- Tool supply-chain review.

OWASP’s excessive agency risk highlights the danger of giving LLM-based systems too much functionality, permission, or autonomy [9]. Agentic AI should therefore be designed with controlled autonomy, not unrestricted action.

AWS’s Generative AI Lens includes a design principle of controlled autonomy, recommending comprehensive guardrails and boundaries around how AI systems operate, scale, and interact [18].

Layer 7: Identity and Access Architecture

Identity architecture defines who the user is, who the agent is, and what each is allowed to access or do.

Enterprise AI identity architecture should include:

- SSO.

- Role-based access control.

- Attribute-based access control where needed.

- User-to-data permission mapping.

- Agent identity.

- Service account controls.

- Delegated authorization.

- Audit attribution.

- Periodic access review.

- Immediate revocation.

This is critical because AI systems can make existing oversharing more visible. If an employee has broad access to files, an AI assistant may summarize those files faster than traditional search. The assistant must not become a shortcut around need-to-know boundaries.

Agent identities deserve special attention. An AI agent should not borrow broad human credentials or operate through a shared admin account. It should have a scoped identity with logged actions and revocation capability.

Layer 8: Security and Privacy Architecture

AI security requires traditional application security plus AI-specific controls.

Security architecture should protect against:

- Prompt injection.

- Indirect prompt injection.

- Sensitive information disclosure.

- Tool abuse.

- Excessive agency.

- Vector and embedding weaknesses.

- Data poisoning.

- Supply-chain vulnerabilities.

- Model denial of service.

- Insecure output handling.

- Unbounded consumption.

- Log and trace leakage.

OWASP’s 2025 LLM Top 10 identifies these risks across LLM and generative AI systems [10]. The EU AI Act and NIST AI RMF also reinforce the need for lifecycle risk management and accountability [5][7].

Privacy architecture should define:

- What data goes into the model.

- What data is logged.

- What is retained.

- What is redacted.

- Whether prompts or outputs are used for training.

- Where data is processed.

- Who can access support logs.

- How data is deleted.

- What data is prohibited.

Major AI providers publish enterprise data-use commitments, but enterprise buyers must review exact products, configurations, and contracts. Privacy is not a vendor promise alone; it is an architecture.

Layer 9: Evaluation Architecture

Evaluation architecture is how the enterprise proves that AI works.

Evaluation should include:

- Golden datasets.

- Expert-labeled examples.

- Historical cases.

- Edge cases.

- Adversarial cases.

- Prompt injection tests.

- Data leakage tests.

- Retrieval tests.

- Citation tests.

- Tool-call tests.

- Human review rubrics.

- Business KPI measurement.

- Regression tests before release.

OpenAI’s evaluation guidance states that generative AI is variable and that evals are a way to test AI systems despite this variability [16]. Microsoft Foundry observability documentation describes built-in evaluators for quality, RAG metrics such as groundedness and relevance, safety and security, and agent-specific metrics such as tool-call accuracy and task completion [19].

Evaluation should be continuous. Every production failure should become a future test case. Every model upgrade should run regression checks. Every new data source should be tested for retrieval quality and security.

Layer 10: Observability Architecture

Observability architecture makes AI behavior visible.

A production AI observability system should track:

- User request.

- User role.

- Model used.

- Prompt version.

- Retrieved documents.

- Source citations.

- Tool calls.

- Tool parameters.

- Guardrail decisions.

- Human approvals.

- Human overrides.

- Latency.

- Token usage.

- Cost.

- Error rate.

- Refusal rate.

- Quality score.

- User feedback.

- Security events.

Microsoft Foundry documentation describes production monitoring that tracks operational metrics, token consumption, latency, error rates, and quality scores, with alerts when outputs fail thresholds or produce harmful content [19].

For enterprise systems, observability is also auditability. If the business cannot reconstruct what happened, it cannot safely scale AI behavior.

Layer 11: Governance Architecture

Governance architecture defines the management system around AI.

A governance architecture should include:

- AI inventory.

- Risk tiering.

- Use-case approval.

- Business owner.

- Technical owner.

- Data owner.

- Security owner.

- Legal and compliance review.

- Model registry.

- Data-source registry.

- Evaluation evidence.

- Monitoring cadence.

- Incident reporting.

- Change control.

- Access review.

- Retirement criteria.

NIST AI RMF is designed to help organizations manage AI risks [5]. ISO/IEC 42001 is the first global AI management system standard and provides requirements and guidance for organizations that develop, provide, or use AI systems [6]. Together, they point toward AI governance as a system, not a document.

Governance must be proportionate. Low-risk AI drafting tools need lightweight controls. High-risk decision systems, agents, and sensitive-data workflows need stronger controls.

Layer 12: Operations Architecture

Operations architecture defines what happens after launch.

Enterprise AI operations should include:

- LLMOps.

- MLOps.

- Prompt management.

- Model lifecycle management.

- Data refresh.

- RAG index maintenance.

- Security reviews.

- Cost management.

- Incident response.

- User support.

- Release management.

- Continuous improvement.

- Vendor monitoring.

- Retirement planning.

Google Cloud’s MLOps guidance emphasizes automation and monitoring across ML system development and operations [14]. OpenAI’s production guidance covers scaling, security, and cost management [15]. These practices are essential because AI systems degrade if data changes, models change, workflows change, or users change.

AI launch is not the end of architecture. It is the beginning of operations.

The Enterprise AI Architecture Patterns for 2026

Most enterprise AI systems will use one or more of the following architecture patterns.

Pattern 1: Enterprise Copilot Architecture

Best for productivity, drafting, summarization, internal search, and user-led workflows.

Core layers:

- User interface.

- Identity-aware context.

- Model access.

- Data privacy controls.

- Output review.

- Usage monitoring.

Risk: overreliance, data exposure through overshared permissions, unsupported outputs.

Pattern 2: Secure RAG Architecture

Best for internal knowledge assistants, policy search, customer support knowledge, legal research support, sales enablement, and technical documentation.

Core layers:

- Source ingestion.

- Metadata and classification.

- Permission-aware retrieval.

- Hybrid search.

- Reranking.

- Prompt assembly.

- Citations.

- Grounded answer generation.

- Retrieval evaluation.

Risk: unauthorized retrieval, stale sources, weak citations, vector index leakage.

Pattern 3: AI Agent Architecture

Best for multi-step workflows with tools, APIs, state, and approvals.

Core layers:

- Goal definition.

- Planning.

- Tool registry.

- Agent identity.

- Tool validation.

- Human approval.

- Execution logs.

- Monitoring.

- Incident response.

Risk: prompt injection, tool abuse, excessive agency, cost loops, data leakage.

Pattern 4: Decision Intelligence Architecture

Best for finance, risk, operations, customer success, supply chain, and executive decision support.

Core layers:

- Data layer.

- Predictive models.

- Rules and policy constraints.

- Explanation layer.

- Human review.

- Outcome monitoring.

Risk: poor explainability, biased recommendations, unclear accountability, overreliance.

Pattern 5: Model Router Architecture

Best for cost and quality optimization across many AI workloads.

Core layers:

- Task classification.

- Model selection policy.

- Quality threshold.

- Cost threshold.

- Fallback routing.

- Evaluation by task.

- Model lifecycle monitoring.

Risk: routing errors, inconsistent behavior, governance complexity.

Pattern 6: AI Platform Architecture

Best for enterprises standardizing AI development across teams.

Core layers:

- Approved model gateway.

- Shared retrieval services.

- Prompt registry.

- Tool registry.

- Evaluation platform.

- Observability.

- Governance workflow.

- Security controls.

- Deployment pipeline.

Risk: platform sprawl, slow adoption if too centralized, weak business ownership.

The Etheon 2026 Enterprise AI Architecture Maturity Model

Level 1: Experimental AI

The enterprise has pilots, chatbots, and productivity tools, but little standardization. Data access and evaluation are inconsistent.

Level 2: Controlled AI

The enterprise has approved AI tools, basic privacy rules, limited pilots, and some governance. Most systems remain department-specific.

Level 3: Production AI

The enterprise has production workflows, defined owners, evaluations, monitoring, risk tiers, and support processes.

Level 4: Platform AI

The enterprise has shared AI architecture: model gateway, secure retrieval, tool registry, evaluations, observability, and governance workflows.

Level 5: Adaptive AI Systems

The enterprise operates AI as an evolving system with continuous evaluation, feedback loops, safe updates, automated monitoring, and business KPI optimization.

Most enterprises in 2026 are between Levels 1 and 3. The strategic opportunity is to move from isolated experiments to platform-enabled production systems.

The 2026 Enterprise AI Architecture Checklist

Before approving a production AI system, enterprise buyers should confirm:

1. Architecture gate: Business architecture

Required evidence: Business owner, KPI, baseline, target, ROI hypothesis

2. Architecture gate: Workflow design

Required evidence: Current state, future state, human role, escalation path

3. Architecture gate: Data architecture

Required evidence: Sources, classification, lineage, freshness, permissions

4. Architecture gate: Retrieval architecture

Required evidence: Secure ingestion, metadata, citations, retrieval evaluation

5. Architecture gate: Model architecture

Required evidence: Model selection, routing, cost, latency, lifecycle plan

6. Architecture gate: Agent architecture

Required evidence: Tool scope, identity, validation, approvals, logs

7. Architecture gate: Security architecture

Required evidence: Prompt injection, leakage, tool abuse, supply chain controls

8. Architecture gate: Privacy architecture

Required evidence: Data flow, retention, redaction, vendor review

9. Architecture gate: Evaluation architecture

Required evidence: Test set, metrics, edge cases, red-team cases

10. Architecture gate: Observability architecture

Required evidence: Logs, traces, cost, quality, tool calls, alerts

11. Architecture gate: Governance architecture

Required evidence: Risk tier, owner, approval, documentation, review cadence

12. Architecture gate: Operations architecture

Required evidence: Support, incident response, model updates, maintenance

If a system cannot pass these gates, it should remain in discovery or pilot.

The 2026 Architecture Roadmap for Enterprise Buyers

Quarter 1: Inventory and Architecture Baseline

- Inventory all AI systems, pilots, tools, and shadow AI.

- Classify use cases by risk and value.

- Identify data sources and permissions.

- Define reference architecture.

- Create AI governance workflow.

- Select production candidates.

Quarter 2: Build the First Production Patterns

- Build one secure RAG system.

- Build one workflow automation system.

- Build one AI assistant or copilot with governance.

- Establish evaluation datasets.

- Create logging and monitoring standards.

- Run red-team testing.

Quarter 3: Standardize the AI Platform Layer

- Create a model gateway or model access policy.

- Build shared retrieval infrastructure.

- Establish tool registry and agent controls.

- Launch observability dashboards.

- Create incident response playbooks.

- Expand only proven workflows.

Quarter 4: Scale Controlled AI Systems

- Scale successful systems across teams.

- Add controlled agents where tool access is proven.

- Review cost and ROI.

- Mature LLMOps and MLOps.

- Update governance and risk classification.

- Build the 2027 roadmap around validated production value.

The Etheon Perspective: Architecture Is the Difference Between AI Activity and AI Advantage

Enterprise AI in 2026 will not be won by the companies with the most pilots. It will be won by the companies that build the most trusted systems.

A trusted enterprise AI system is not only a model. It is a designed operating capability:

- It knows its purpose.

- It uses approved data.

- It respects permissions.

- It cites evidence.

- It limits actions.

- It asks for approval when needed.

- It logs behavior.

- It passes evaluations.

- It can be monitored.

- It can be stopped.

- It has owners.

- It improves over time.

That is the architecture standard for 2026.

For Etheon, the central conclusion of this flagship report is direct:

Enterprise AI architecture must move from model access to system design.

The winners of the next phase will design AI systems around business outcomes, governed data, secure retrieval, controlled agents, continuous evaluation, observability, and responsible operations.

That is how enterprises move from AI experimentation to AI advantage.

References

[1] McKinsey, “The State of AI: Global Survey 2025.” https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai
[2] Deloitte, “The State of AI in the Enterprise — 2026 AI Report.” https://www.deloitte.com/us/en/what-we-do/capabilities/applied-artificial-intelligence/content/state-of-ai-in-the-enterprise.html
[3] Stanford HAI, “The 2026 AI Index Report.” https://hai.stanford.edu/ai-index/2026-ai-index-report
[4] Gartner, “Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027.” https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027
[5] NIST, “AI Risk Management Framework.” https://www.nist.gov/itl/ai-risk-management-framework
[6] ISO, “ISO/IEC 42001:2023 — AI Management Systems.” https://www.iso.org/standard/42001
[7] European Commission, “AI Act — Regulatory Framework.” https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
[8] OWASP GenAI Security Project, “LLM08:2025 Vector and Embedding Weaknesses.” https://genai.owasp.org/llmrisk/llm082025-vector-and-embedding-weaknesses/

[9] AWS Well-Architected Generative AI Lens, “Design Principles.” https://docs.aws.amazon.com/wellarchitected/latest/generative-ai-lens/design-principles.html
[10] OWASP, “Top 10 for Large Language Model Applications.” https://owasp.org/www-project-top-10-for-large-language-model-applications/assets/PDF/OWASP-Top-10-for-LLMs-v2025.pdf
[11] NIST, “AI RMF 1.0 PDF: Govern, Map, Measure, Manage.” https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf
[12] ISO, “ISO 42001 Explained.” https://www.iso.org/home/insights-news/resources/iso-42001-explained-what-it-is.html
[13] AWS, “Generative AI Lens — Well-Architected Framework.” https://docs.aws.amazon.com/wellarchitected/latest/generative-ai-lens/generative-ai-lens.html
[14] Google Cloud, “MLOps: Continuous Delivery and Automation Pipelines in Machine Learning.” https://docs.cloud.google.com/architecture/mlops-continuous-delivery-and-automation-pipelines-in-machine-learning
[15] OpenAI, “Production Best Practices.” https://developers.openai.com/api/docs/guides/production-best-practices
[16] OpenAI, “Evaluation Best Practices.” https://developers.openai.com/api/docs/guides/evaluation-best-practices
[17] CISA and partners, “AI Data Security: Best Practices for Securing Data Used to Train and Operate AI Systems.” https://services.google.com/fh/files/misc/practitioners_guide_to_mlops_whitepaper.pdf
[18] AWS, “Generative AI Lens Design Principles: Controlled Autonomy.” https://docs.aws.amazon.com/wellarchitected/latest/generative-ai-lens/design-principles.html
[19] Microsoft Learn, “Observability in Generative AI — Microsoft Foundry.” https://learn.microsoft.com/en-us/azure/foundry/concepts/observability