Enterprise AI solution: core components and requirements

The capex question is no longer about the model

Enterprise AI spending has shifted from a discretionary innovation line to a compliance budget. The EU AI Act entered into force on August 1, 2024. Its prohibitions and AI literacy obligations landed on February 2, 2025. General-purpose AI rules take effect August 2, 2025. The regulation is scheduled to be fully applicable on August 2, 2026, with high-risk systems embedded in regulated products carrying an extended transition until August 2, 2028. Each of those dates is procurement timing — but the deadline that binds depends on the system's classification, whether it falls inside the Act's scope in the first place, and which transition rule applies.

A prohibited-practice deployment shipped this morning is already non-compliant. A high-risk system in a regulated product has until August 2, 2028 to converge, provided the formal transition conditions hold. A general-purpose AI model triggers its own obligations on August 2, 2025, separate from the deployment rules. Limited-risk systems carry information obligations, not conformity assessment. Minimal-risk systems face no binding deadline but the voluntary code-of-conduct route. The auditor does not care which deadline the procurement team was watching. The auditor cares which one actually applied to the system that shipped on the day it shipped.

An enterprise AI solution, properly defined, is not a model wrapped in a chatbot. It is a stack of governance, data integration, security, and lifecycle controls that survives an audit and operates across jurisdictions. The architecture varies by sector, risk tier, and use case — but the structural pillars are now codified. Standards bodies have done the work. The procurement question is whether the deployment is built to that standard or borrowed from a consumer demo.

The Governance Framework: Beyond Model Performance

Governance is the function that swallows everything else. NIST AI RMF 1.0, released January 26, 2023, organizes AI risk management into four functions: Govern, Map, Measure, and Manage. Governance is cross-cutting. The other three apply to specific AI-system contexts and lifecycle stages. The structure is deliberate — without a governance spine, the other three functions have no owner, no escalation path, and no budget line.

The international counterpart is ISO/IEC 42001:2023, published in December 2023. The document runs 51 pages and specifies requirements for an Artificial Intelligence Management System (AIMS). It applies to organizations that develop, provide, or use AI-based products or services. Certification is voluntary in most jurisdictions, but the procurement market is moving faster than the regulators. Financial services, healthcare, and regulated industries are already writing AIMS-style requirements into vendor RFPs. The standard is becoming a market precondition, not a legal mandate.

The translation is straightforward. Vendors that conflate "AI safety" with a feature flag are selling the wrong product. The governance layer is a management system with documented ownership, policy review cycles, and incident response procedures. It is the operating model, not the dashboard. The capital cost is real — headcount, audit, external assurance — and the companies that have not priced it into the SKU are about to.

Governance is not a feature. It is a management system with a budget, an owner, and an audit trail.

Trustworthiness and Risk Management Standards

NIST identifies seven trustworthiness characteristics for AI systems: valid and reliable; safe; secure and resilient; accountable and transparent; explainable and interpretable; privacy-enhanced; and fair with harmful biases managed. These are not aspirations. They are the control surface against which an enterprise AI solution is measured, and the surface area is broader than most procurement teams realize.

The measurement function under NIST AI RMF is specific. AI systems should be tested before deployment and regularly while operating. Measurement processes should include performance assessment, uncertainty measures, benchmark comparisons, and documented results. The keyword is "documented." Undocumented tests do not exist for compliance purposes. The teams that have absorbed this discipline are the ones who have run regulated software for decades. The teams discovering it now are paying the learning curve in legal fees.

The Generative AI Profile — NIST AI 600-1, published July 26, 2024 — extends the core framework to generative systems. The profile was informed by a public working group of more than 2,500 volunteers and covers evaluation, governance, and content provenance. The financial industry implication is direct. Any enterprise AI solution that handles regulated content — credit memos, underwriting notes, patient communications, legal discovery — needs to map to this profile. Vendors that cannot produce a mapping document are not enterprise-grade. They are pitching demos.

The "valid and reliable" characteristic deserves a separate callout. A model that produces different outputs for identical inputs is not a reliability problem to be patched. It is a system defect. The mitigation is process control: deterministic pipelines, evaluation harnesses, and reproducibility checks. Anything less is a debugging claim, not a reliability claim, and it will not survive an audit.

Securing the AI Stack: Mitigating OWASP LLM Risks

OWASP's current Top 10 for LLM Applications lists the risk categories relevant to enterprise generative AI deployments: prompt injection, insecure output handling, sensitive-information disclosure, excessive agency, overreliance, supply-chain vulnerabilities, and model denial of service. Each category has a documented mitigation pattern. Each represents a class of incidents that already has case law in enterprise software — the LLM is the new surface, but the loss vectors are familiar.

Excessive agency is the standout. OWASP describes it as a risk caused by excessive functionality, permissions, or autonomy. The mitigations are operational: limit the tools an agent can call, grant only necessary permissions, avoid open-ended tools where possible, log and monitor downstream activity, and rate limit. The implication is that agent design is a permissioning exercise, not a prompt engineering exercise. The system prompt is not a security boundary. Credentials, connection strings, and authorization logic do not belong in it. OWASP warns that prompts can be exposed or bypassed — and that is the operative word.

The investment angle is direct. The vendors treating LLM security as a wrapper around an API are pricing the wrong risk. The actual loss surface is the agent's permissions, the model's training data lineage, and the output handling pipeline. Underwriting this risk requires the same discipline as enterprise software security — threat modeling, control testing, and continuous monitoring. The companies best positioned to sell this are the ones with existing enterprise security distribution. The capital will follow the controls, not the demos.

A system prompt is not a security boundary. Treat agent design as a permissioning exercise, not a prompt engineering exercise.

Compliance and Lifecycle Documentation Requirements

The EU AI Act does not apply to every AI system. It applies to systems within its scope, with high-risk systems carrying the heaviest obligations. For high-risk systems, the regulation requires a documented, continuous, and iterative risk-management system across the lifecycle. This is not a one-time assessment. It is a program — with version control, ownership, and review cadence.

Data governance is explicit. Training, validation, and testing datasets require attention to data origin, preparation, suitability, and potential bias. Data lineage is now a regulatory requirement, not a best practice. Vendors that cannot produce a data card and a model card are not in the high-risk pipeline, and they are not a procurement-grade answer for a regulated workflow.

The retention numbers are where the capex math gets sharp. Automatically generated logs under the provider's or deployer's control must be kept for an appropriate period and at least six months, unless other applicable law provides otherwise. Specified technical and quality-management documentation must be retained for ten years after the system is placed on the market or put into service. Ten years is a long time. It spans model versions, vendor changes, and regulatory regimes. The records-retention budget is a material operating cost — and it scales with every model variant, every regional deployment, and every vendor update.

An enterprise AI system handling regulated data is not allowed to ship on hype. It ships on documentation, retention, and a paper trail that survives an audit three regimes from now. The feedback loop that consumer products absorb through reviews and return rates does not transfer cleanly. The recall cost here is measured in enforcement action, fines, and the slow walk of remediation under regulator scrutiny — not in shipping the next SKU.

Operationalizing Zero-Trust for AI Agents

Zero-trust is not a product. NIST's guidance is unambiguous: trust should not be implicitly granted based only on network location or asset ownership. Authentication and authorization for both the subject and device are separate functions performed before access to an enterprise resource is established. The principle is that authorization is a continuous gate, not a perimeter check.

For AI agents, the application is uncomfortable. An agent acting on behalf of a user inherits the user's identity — but it does not inherit the user's intent, the user's risk tolerance, or the user's accountability. The agent's permissions are an independent decision. Granting an agent broad write, delete, payment, production, or customer-data permissions without independent authorization controls is not a configuration choice. It is a fiduciary liability. The enterprise AI solution that treats this as a soft policy is a lawsuit waiting for a settlement date.

The mitigation pattern is borrowed from privileged access management. Session-level authorization, time-bound credentials, just-in-time elevation, and human approval for high-impact actions. The agent's tool registry is a permission boundary. The agent's logging is a forensic artifact. The agent's rate limits are a circuit breaker. OWASP's guidance is consistent: limit tools, grant only necessary permissions, avoid open-ended functions, log downstream activity, and rate limit.

The architecture needs to enforce these controls at the integration layer, not at the prompt layer. Adding a sentence to the system prompt saying "do not exfiltrate data" is a wish, not a control. The control is the network policy, the API gateway, the database role, and the audit log. The enterprise AI solution that cannot produce a control diagram is a prototype, not a product — and the procurement team that signs the PO on the demo will be explaining the controls retroactively.

The cost of admission

The benchmarks for enterprise AI ROI are not universal. They depend on the specific workflow, the baseline, the sector, and the measurement method. Any vendor quoting a single percentage point as typical is selling a slide. The honest answer is that ROI is a defined function of inputs the enterprise controls — and the vendors worth their pricing have to be challenged on those inputs, not on the headline number.

The market is sorting itself. The vendors that have absorbed the regulatory discipline — documentation, retention, governance, testing — are pricing accordingly. The vendors that have not are competing on model performance and discounting through compliance. The procurement teams that understand the difference will pay the former and document the rationale. The procurement teams that do not will be explaining the budget overruns in 2027.

The benchmarks for model selection, retraining cadence, and acceptable hallucination rate are not sector-neutral. They are workflow-specific, jurisdiction-specific, and contract-specific. Treating them as universal is the first mistake a procurement team makes, and it is the mistake the vendors with the weakest control surface are most eager to enable.

The path forward is operational discipline. The standards exist. The deadlines are not negotiable. The capital is moving toward the vendors that have built the operating model. The enterprises that treat this as a multi-year program — governance, testing, documentation, retention — are the ones whose AI deployments will still be in production in 2030. The rest will be relitigating the procurement decision in front of a regulator.