AI Operating System for Enterprises: How AIOS Reorganizes Enterprise AI

An AI operating system for enterprises connects data, models, knowledge, applications, and AI agents through a shared control architecture. AIOS keeps assistants from operating as isolated tools by enforcing permissions, workflow rules, and quality controls. For mid-sized companies, it provides the foundation for moving AI from occasional assistance to governed operational execution.

What is an AI operating system for enterprises, and what does AIOS mean?

A conventional operating system manages computing resources such as processors, memory, files, devices, and access rights. Applications do not need to rebuild those basic services every time they are developed. AIOS applies a similar principle to artificial intelligence applications and agents.

The term has more than one meaning. In academic research, AIOS refers to a specific open-source architecture designed to operate multiple LLM-based agents. Its kernel separates agent applications from shared services such as model access, scheduling, context management, memory, storage, tool management, and access control. An SDK gives developers a standardized interface for using those kernel services. The underlying paper was published at COLM 2025.

Within an enterprise, the idea is broader. An enterprise AIOS is not necessarily one packaged product, and it does not replace Windows, Linux, ERP software, or business applications. It is the common control layer through which models, data sources, AI agents, workflows, permissions, approvals, evaluations, and operational policies work together.

This article therefore uses AIOS as an architectural concept. A company may assemble it from a model gateway, agent runtime, Company Brain, integration services, identity platform, policy engine, observability tools, and existing business applications.

The purpose is to prevent every department from building its own isolated AI stack. Instead of separate assistants with duplicated connectors, inconsistent permissions, and unrelated model contracts, the company creates reusable services that can support multiple business processes.

Why is demand for enterprise AIOS emerging now?

Many organizations began with individual AI tools. Marketing used a writing assistant, knowledge management deployed document search, meeting software generated summaries, and customer support experimented with a chatbot. These systems could deliver value without coordinating many business applications.

The next stage is materially different. AI agents are expected to identify customers, review records, retrieve internal knowledge, prepare proposals, schedule work, update systems, and trigger selected transactions. Once an AI system can act across multiple applications, the challenge moves from prompt design to operational control.

The 2026 AI Index reports that organizational AI adoption has reached 88 percent among the surveyed organizations. That figure does not mean that most companies already have mature agent platforms. An organization can use AI extensively for writing or analysis while lacking consistent identity, evaluation, process ownership, and execution controls.

Eurostat reports that 19.95 percent of European Union enterprises used at least one of the measured AI technologies in 2025. Large enterprises reported much higher usage, with the difference associated with implementation complexity, expertise, available investment, and economies of scale. Mid-sized companies therefore face a practical architecture challenge: access to models has become easier, but dependable operational integration remains demanding.

The shift toward action-oriented AI is already visible. In Microsoft’s 2025 Work Trend Index, 46 percent of surveyed leaders said their organizations were using agents to fully automate workflows or business processes. The result should not be interpreted as proof that almost half of companies operate fully mature autonomous systems. It does demonstrate that the market is moving beyond text generation toward coordinated execution.

As execution expands, organizations need shared policies, permissions, and operating controls. That is the problem an AI operating system for enterprises is intended to address.

Why is one copilot no longer enough?

A copilot typically assists a person within a defined application. It may draft an email, summarize a document, explain a spreadsheet, or answer questions about a knowledge base. For contained tasks, this pattern can be entirely appropriate.

The limitations appear when work crosses organizational boundaries. Consider a customer asking to modify an existing service agreement. The AI must identify the customer, locate the active contract, review service conditions, determine financial implications, obtain approval, update the system of record, and send confirmation.

One assistant may have too little access to complete the process. Giving it broader access creates the opposite problem: it may receive permission to view or modify far more information than the task requires.

Organizations often respond by adding more bots. A sales assistant connects to CRM, a knowledge assistant searches documents, a support bot reads tickets, and another agent prepares quotes. Each solution has its own prompts, connectors, credentials, logs, and model settings.

This bot collection appears productive during early pilots because teams can move independently. Over time, however, the company must maintain duplicated integrations, reconcile inconsistent answers, review overlapping permissions, and trace which assistant performed which action.

AIOS moves those shared concerns out of individual assistants. Identity, model routing, context delivery, tool permissions, approval requirements, and monitoring become platform capabilities. Each assistant remains specialized, but it operates inside an enterprise control structure.

Which capabilities belong in the AIOS control layer?

An enterprise AIOS normally consists of several functional layers. Vendors may package them differently, but the operating responsibilities remain broadly similar.

The experience layer provides access for employees, customers, and partners. It may include chat interfaces, voice services, portals, mobile applications, or assistants embedded directly into ERP, CRM, field-service, engineering, and productivity software.

Below that sits the agent and process layer. It interprets requests, decomposes larger tasks, selects capabilities, coordinates specialized agents, and transfers work between automated steps and human decision makers. It should also manage pauses, retries, exceptions, timeouts, and reversals.

A model layer controls access to language models and other AI services. Different tasks may require different combinations of reasoning ability, speed, cost, language support, multimodal input, privacy, and regional hosting. A central gateway can select the appropriate model class rather than binding every application directly to one provider.

The context and knowledge layer supplies business information. It connects structured records from databases and systems of record with documents, policies, project experience, and a Company Brain. It must preserve information about source, version, ownership, applicability, and approval status.

The tool layer exposes permitted business actions. Agents do not receive unrestricted database access. They use defined capabilities such as retrieving a customer record, checking inventory, creating a ticket draft, reserving an appointment, or preparing an order for approval.

The control layer then manages identities, policies, logs, evaluations, budget limits, security events, and administrative intervention. Without this layer, an agent platform may work as a demonstration but remain difficult to operate as enterprise infrastructure.

How does AIOS differ from ERP, a Company Brain, and an agent framework?

These technologies serve different purposes and should not be treated as interchangeable.

AIOS does not remove the need for these systems. It coordinates their contribution.

ERP remains the authoritative location for an order or invoice. A Company Brain provides the relevant knowledge. An integration platform transfers data or runs a deterministic workflow. An agent framework supplies development components. AIOS determines which agent may use which knowledge, which model, and which business action under which approval conditions.

This distinction is particularly important for procurement. A product may advertise an AI assistant without providing an enterprise control layer. Another platform may offer sophisticated agent development while depending on external systems for identity, governance, and production monitoring.

What does an end-to-end AIOS workflow look like?

Consider a mid-sized technical services company receiving an email about a malfunctioning customer asset. The customer describes the symptom but does not provide an asset number or previous work-order reference.

An intake service identifies the sender, language, request type, and operational priority. Through a permitted CRM function, the customer record is resolved. The Company Brain retrieves the installed asset, service history, previous symptoms, manufacturer information, and relevant internal procedures.

A service agent prepares an operational summary and proposes next actions. It does not yet have permission to commit the company to a billable visit. A separate contract function checks service coverage, while a scheduling capability identifies suitable technicians and available appointment windows.

The AIOS policy engine determines which cases may proceed automatically. Work covered by an active service agreement might be saved as a draft without additional commercial review. Work outside the agreement requires approval from an authorized employee.

The dispatcher receives a decision package rather than an unsupported response: identified customer, affected asset, prior faults, contract status, proposed appointment, required skills, and the sources used to prepare the recommendation.

After approval, the AIOS creates the work order in ERP, reserves the slot, and sends the customer confirmation. Following the visit, the technician’s report, photographs, measurements, and approved findings return to the knowledge layer.

This workflow combines interpretation, knowledge retrieval, deterministic rules, human approval, and system execution. A basic chatbot may handle the first conversation, but it cannot reliably operate the entire process without the surrounding control architecture.

What role do enterprise data and a Company Brain play?

An AI operating system does not require one giant copy of every business record. Building such a copy would increase synchronization effort, privacy exposure, and the risk that AI uses data that no longer matches the authoritative application.

Transactional data should generally remain in the relevant system of record. Customer accounts, orders, inventory positions, invoices, and employee schedules are retrieved through defined functions when the task requires them.

Documents, operating procedures, product knowledge, project decisions, and experience can be organized through a Company Brain. The knowledge layer should preserve sources, revisions, applicability, ownership, and review status rather than presenting every document as equally authoritative.

A Company Brain is therefore a major component of AIOS, but it is not the entire operating system. It manages organizational knowledge. AIOS additionally manages agents, models, permissions, tools, approvals, evaluations, and execution.

Most valuable workflows require both forms of information. A quoting agent may read current pricing and availability from ERP while retrieving approved scope language, engineering guidance, and lessons from comparable projects from the Company Brain.

Context should be assembled for the specific task. An agent scheduling a maintenance appointment does not need the customer’s complete commercial history or access to internal margin calculations. Data minimization should be enforced by architecture and permissions, not merely requested in a prompt.

How are models, agents, and tools orchestrated?

Early AI applications often hard-code one language model. That approach becomes restrictive in an enterprise AIOS because models differ in cost, speed, reasoning, context capacity, language support, multimodal performance, tool reliability, and suitability for sensitive workloads.

A model gateway can abstract the providers. The business application specifies the task and operating requirements instead of calling one model directly. The AIOS then selects an appropriate model class and can fall back to another provider if a service is unavailable or fails evaluation.

The same principle applies to agents. A customer-service agent does not need to contain contract analysis, scheduling, document generation, and billing logic within one large prompt. It can call specialized capabilities while the orchestration layer manages dependencies, state, retries, and escalation.

The research AIOS architecture focuses on closely related runtime concerns. It centralizes scheduling for competing agent requests, context management, memory, storage, tool access, and permissions. In its published experiments, the system achieved up to 2.1 times faster execution for the evaluated agent workloads. This result should not be converted into a general performance promise for enterprise implementations, but it demonstrates why shared resource management becomes relevant when many agents operate concurrently.

Enterprise orchestration must go further than technical runtime management. A successful tool call does not mean that a business process was completed correctly. The control layer also needs deadlines, approval thresholds, responsibilities, exception handling, compensation steps, and evidence of why an action was permitted.

What do MCP and A2A contribute to an enterprise AIOS?

Open protocols can reduce the number of proprietary connections required between AI systems and enterprise applications.

The Model Context Protocol, or MCP, standardizes how AI applications connect to data sources, tools, and workflows. An MCP server might expose capabilities for searching CRM, retrieving documents, checking an appointment calendar, or creating a controlled draft record. The current specification includes requirements covering connection lifecycle, capability negotiation, tools, resources, and authorization.

The Agent2Agent protocol, or A2A, addresses communication between independent agents. It enables agents developed on different frameworks or platforms to advertise capabilities, exchange tasks, and communicate status. The project was transferred to the Linux Foundation to support vendor-neutral governance and broader interoperability.

MCP and A2A are building blocks rather than complete operating systems. Neither protocol provides the organization’s process ownership, identity architecture, financial controls, audit model, evaluation strategy, or incident response.

Standards also do not make every connected service safe. A broadly permissioned MCP server can expose excessive actions even when it implements the protocol correctly. Enterprise teams still need to review each tool, credential, scope, data path, and failure mode.

How should identities, permissions, and approvals be designed?

The most dangerous agent is not necessarily the one with the least capable model. A powerful agent with excessive data access and transaction rights can create far greater operational risk.

AIOS therefore needs identities for people, agents, and technical services. Each agent should have a documented owner, business purpose, permitted data classes, approved tools, operating environment, and escalation path.

Permissions should be action-specific. A quoting agent may read product data and save a draft proposal but should not modify master pricing or issue a purchase order. A service agent may suggest an appointment while requiring an employee to confirm the commitment.

Higher-impact actions need stronger controls. These may include financial transactions, contract modifications, deletion, employee-related decisions, publication of external content, and changes to production systems. Depending on risk, the company may use dual approval, monetary thresholds, preview screens, simulation, or strict separation between recommendation and execution.

Credentials should be stored in centralized secrets management rather than prompts, agent code, or unrestricted configuration files. Logs should connect each action to the requesting person, agent identity, policy decision, sources, tool calls, and final result.

AIOS also needs operational stop controls. Administrators should be able to disable one agent, connector, model, or action without shutting down every AI-supported process.

How does governance become part of daily AI operations?

Governance cannot remain a policy document that employees are expected to remember while building agents. AIOS must translate policy into enforceable operating behavior.

A policy may state that selected data classes cannot be processed by an external model. The platform enforces that rule through model routing, redaction, or local processing. Another policy may prohibit automated employee evaluation. The orchestration layer then blocks the action or requires an authorized human decision.

Each AI system should have a documented purpose, owner, model set, data sources, affected groups, expected impacts, evaluation method, and approval history. Model and prompt changes need versioning because behavior may change even when the surrounding business process remains the same.

The NIST AI Risk Management Framework organizes risk-management activities through Govern, Map, Measure, and Manage. Its generative AI profile addresses risks associated with generative systems and proposes corresponding actions. The framework is voluntary, but it offers a useful operating model for technical and organizational controls.

Companies operating in Germany or elsewhere in the European Union also need to account for the EU AI Act. The European Commission states that AI literacy requirements already apply, while additional major provisions and transparency obligations become applicable on August 2, 2026, subject to exceptions and separate transition periods for certain high-risk systems. AIOS can support inventories, roles, approvals, logs, and evidence, but it does not replace legal analysis for a specific use case.

What commonly goes wrong in AIOS initiatives?

The first failure pattern is attempting to design a universal enterprise platform before proving one useful end-to-end workflow. The program becomes dominated by architecture diagrams, tool comparisons, and hypothetical agents while employees continue using manual processes.

A second pattern is the uncontrolled bot portfolio. Each department builds an assistant with independent data copies, connectors, credentials, and prompts. Early delivery appears fast, but later maintenance becomes expensive and permissions become difficult to audit.

Organizations also mistake an agent framework for a complete operating platform. Frameworks can simplify agent development and task coordination, but they do not automatically provide enterprise identity, privacy controls, cost allocation, process ownership, audit evidence, or operational support.

A Company Brain may be stretched beyond its intended role as well. Knowledge retrieval can find policies and explain prior decisions. It does not automatically grant authority to change a customer account, approve a payment, or evaluate an employee.

Another recurring mistake is granting too much autonomy during the pilot. Once an agent can call multiple tools, manual approval is treated as an obstacle. A safer sequence begins with recommendations and drafts, then expands execution only after exceptions, errors, and reversal paths are understood.

Some projects also measure demonstrations rather than business performance. A sophisticated multi-agent conversation is not valuable if the actual workflow becomes slower or requires more corrections.

Finally, AIOS cannot improve without operational telemetry. Companies need information about model spend, failed tool calls, escalations, abandoned workflows, human overrides, and the reasons employees reject recommendations.

How can a mid-sized company start without a major platform program?

The first implementation should cover a complete but bounded process. A suitable workflow occurs frequently, depends on several information sources, and creates measurable manual effort today.

Qualified customer inquiries are one example. The workflow begins with intake, continues through customer identification, knowledge retrieval, follow-up questions, scheduling or quote preparation, and ends with a documented record in the relevant system of record.

Before selecting software, the organization maps the systems, data owners, decision rights, and approval thresholds involved. Each step is classified as information retrieval, recommendation, draft creation, or actual transaction execution.

The initial architecture does not require a large multi-agent environment. A small set of shared services may be enough: identity, knowledge retrieval, process control, model routing, tool gateway, and logging. The important design decision is to make those capabilities reusable.

The pilot should use real work rather than staged examples. Employees evaluate recommendations, mark missing evidence, and record why they accepted or rejected an output. These observations may reveal problems in the source data, operating rules, or process design that cannot be solved by prompt changes alone.

Additional agents, departments, and execution rights should be added only after the first workflow performs consistently and can be supported operationally.

Which use cases are appropriate for an initial AIOS deployment?

Customer service is a practical starting point when employees currently switch among CRM, ticketing, email, contracts, and knowledge repositories. AIOS can identify the customer, categorize the request, retrieve relevant knowledge, and prepare a response or ticket draft.

Sales teams can use the platform to enrich inbound leads, summarize conversations, suggest follow-up actions, and assemble approved proposal content. Pricing decisions and contractual commitments can remain under employee control during the initial stage.

Procurement workflows can review requests, retrieve supplier information, check preferred-vendor policies, and prepare orders. Spending thresholds and approval rules must be enforced in the tool layer rather than described only in natural-language instructions.

Technical service organizations can connect asset records, work history, manufacturer documentation, fault patterns, and spare-parts information. The field employee receives an asset-specific work package rather than a generic answer.

Internal administration can also benefit through recurring report preparation, document intake, approval coordination, and record classification. Early projects should avoid high-impact employment, safety, or financial decisions unless the organization already has mature controls and specialist review.

How should the economic value of AIOS be measured?

The number of agents deployed is not a meaningful business outcome. Value must be evaluated at the workflow level.

Relevant operating measures include cycle time, manual handoffs, follow-up questions, rework, abandonment, and time to a professional decision. Technical measures include model cost per case, latency, tool errors, retries, and the proportion of cases escalated to employees.

Quality also needs a process-specific definition. In quoting, the company may assess whether required scope items were included, approved sources were used, and commercial approval rules were followed. In service, quality may depend on correct customer identification, complete asset history, and reduced repeat communication.

A high automation rate is not necessarily positive. If an AIOS completes many cases automatically but increases complaints, corrections, or financial leakage, it has shifted rather than removed work.

The reuse effect is especially important for mid-sized companies. The first workflow may not justify every platform component by itself. AIOS becomes economically attractive when identity, tool access, knowledge retrieval, logs, evaluations, and model routing support additional workflows without being rebuilt.

When is an enterprise AIOS premature?

A company does not need an AI operating system merely because employees use generative AI for occasional writing or analysis. A standalone assistant or well-governed knowledge search may be more proportionate.

Processes that change constantly are also poor starting points. AIOS cannot stabilize work that has no accepted ownership, inputs, outputs, or decision rules.

Weak digital source systems create another constraint. An agent cannot reliably check inventory if stock information is maintained in personal spreadsheets. It cannot apply contract rules if approved versions cannot be distinguished from drafts.

AIOS becomes relevant when multiple AI applications need the same models, data, tools, identities, and controls. The business case comes from shared services and coordinated execution rather than the platform label.

How does AIOS change enterprise software procurement?

With AIOS, companies evaluate more than the AI feature visible in a product demonstration. They must consider how the product participates in a broader operating architecture.

A business application should ideally provide documented APIs, granular permissions, event interfaces, export options, and useful logs. A proprietary assistant may still be valuable, but it is harder to coordinate when its sources, actions, and policy decisions cannot be accessed.

Open protocols can reduce platform dependence, but protocol support should not become a checkbox exercise. Procurement teams need to understand which tools are exposed, how authorization works, whether actions are reversible, and how the vendor handles version changes.

The model strategy changes as well. A durable AIOS should not assume that one provider will always offer the best combination of quality, cost, privacy, availability, and regional requirements for every task.

Contracts should address submitted data, retention, training use, subprocessors, service continuity, incident handling, model changes, and export. These terms affect the operating model as much as the application’s visible functionality.

How should a company decide what belongs in the platform and what remains local?

Shared platform services are appropriate when multiple use cases need the same capability. Examples include identity, model routing, knowledge retrieval, tool authorization, logs, evaluations, and policy enforcement.

Business-specific decisions should remain close to the responsible process. A central platform team can operate the model gateway and security controls, while the service department owns rules for dispatch and the finance team owns payment approvals.

Some workloads may remain local or within a private environment because of sensitivity, latency, or system dependencies. Other tasks can use external models when they require specialized capabilities or variable capacity.

AIOS should support this hybrid structure rather than require all data and inference to move to one location. The control layer records which route was selected and why it was permitted.

This division also prevents the central AI team from becoming the owner of every business rule. Platform ownership and process ownership must remain distinct.

How will AIOS evolve over the next several years?

The technical landscape is moving from isolated assistants toward networks of specialized agents. In parallel, standards are emerging for tool access, contextual data, and agent-to-agent communication. These developments support stronger separation between business applications, agent logic, and shared control services.

Most companies will not build a complete AI operating system from the ground up. They are more likely to combine a cloud platform, integration services, Company Brain, identity provider, model access layer, policy controls, and selected custom components.

Local models and hybrid processing will remain important. Sensitive or repetitive work may run internally, while external models handle less sensitive or more demanding reasoning tasks. AIOS can route work according to the data class and required capability.

Models will continue to change faster than many business systems. The organization’s durable assets will therefore be its process definitions, knowledge, permissions, evaluations, integrations, and operating experience.

The operating-system analogy is most useful as a design principle. Shared services are managed centrally, business applications remain replaceable, and agents receive only the resources required for their assigned work.

What is the practical conclusion for mid-sized companies?

An AI operating system for enterprises becomes relevant when AI begins to connect knowledge, applications, and decisions across multiple steps rather than merely producing text.

Mid-sized companies do not need the largest possible platform. They need reusable foundations: governed knowledge access, limited tools, model routing, role-based permissions, approvals, logs, evaluation, and measurable operating rules.

AIOS provides the bridge between individual AI applications and durable business infrastructure. The decisive work is not choosing the most impressive model. It is designing the operating controls around the model.

KrambergAI GmbH, https://krambergai.com/, develops these architectures for mid-sized organizations, combining Company Brain capabilities, AI agents, system integration, and governed process execution.

What is AIOS in one sentence?

AIOS is a shared operating and control layer for models, AI agents, enterprise knowledge, applications, and policies. It provides reusable services so that every AI application does not need to build separate connectors, permissions, context handling, and controls. The term may describe a specific research architecture or a broader enterprise design.

Is an AI operating system a packaged software product?

Not necessarily. Some vendors use AIOS as a product name, while enterprises often use the term for a combined target architecture. That architecture may include a model platform, agent framework, Company Brain, integration services, identity management, and observability. The defining feature is shared operational control rather than purchasing one product labeled AIOS.

Does AIOS replace ERP or CRM?

No. ERP and CRM remain the authoritative systems for transactions and master records. AIOS accesses them through controlled functions, combines their data with enterprise knowledge, and coordinates the resulting work. A customer update is still stored in CRM, even when an agent prepares the change and routes it through approval.

How is AIOS different from a Company Brain?

A Company Brain organizes and retrieves enterprise knowledge. AIOS uses that knowledge while also managing agents, models, permissions, tools, and process execution. The Company Brain may identify which policy applies to a request. AIOS connects that answer to an authorized action, approval requirement, and system transaction.

Does every enterprise need multiple AI agents?

No. An AIOS can begin with one assistant and a limited set of controlled tools. Multiple agents become useful when tasks require different expertise, permissions, or execution logic. Creating unnecessary agents increases coordination overhead, cost, and potential failure modes without guaranteeing better workflow outcomes.

Can AIOS use several language models?

Yes. A central model layer can route tasks according to privacy, cost, speed, language, and required capability. This enables combinations of local and external models. Applications should avoid unnecessary dependence on one provider, although model interchangeability still requires evaluation because tool use and structured outputs vary.

How does AIOS protect sensitive enterprise data?

Protection depends on role-based access, data minimization, separate identities, limited tools, encryption, and logs. Agents receive only the context required for the task. The organization must also define which information external models may process and which data must remain in a local or otherwise restricted environment.

Which systems should be connected first?

The first integrations should support one selected end-to-end workflow. For a service request, these might include CRM, ticketing, scheduling, and the Company Brain. Connecting every enterprise application at the beginning creates substantial work without immediate value. Integration priorities should follow the operational use case.

Does AIOS require MCP or A2A?

No. Both protocols can improve interoperability, but neither is mandatory for every implementation. Existing REST APIs, events, and workflow connectors remain useful. MCP primarily supports standardized tool and context access, while A2A focuses on communication and task exchange among independent agents.

Does an AI operating system replace employees?

AIOS primarily takes over information retrieval, preparation, coordination, and repeatable system actions. Professional accountability, exceptions, relationships, and high-impact decisions remain human responsibilities. Roles will still change as employees review prepared results, handle unusual cases, and maintain operating rules instead of performing every routine step manually.

Sources for the metrics used

Stanford Institute for Human-Centered Artificial Intelligence: The 2026 AI Index Report
Metric used: organizational AI adoption reached 88 percent.
https://hai.stanford.edu/ai-index/2026-ai-index-report

Eurostat: Use of artificial intelligence in enterprises
Metric used: 19.95 percent of EU enterprises used at least one measured AI technology in 2025.
https://ec.europa.eu/eurostat/statistics-explained/index.php?title=Use_of_artificial_intelligence_in_enterprises

Microsoft: The 2025 Annual Work Trend Index
Metric used: 46 percent of surveyed leaders reported using agents to fully automate workflows or business processes.
https://blogs.microsoft.com/blog/2025/04/23/the-2025-annual-work-trend-index-the-frontier-firm-is-born/

Kai Mei et al.: AIOS – LLM Agent Operating System
Metric used: up to 2.1 times faster execution in the evaluated agent workloads.
https://arxiv.org/abs/2403.16971

Further reading

European Commission: Regulatory framework for artificial intelligence and the AI Act
https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai

Model Context Protocol: Official specification
https://modelcontextprotocol.io/specification/2025-11-25

NIST: Artificial Intelligence Risk Management Framework
https://www.nist.gov/itl/ai-risk-management-framework