What Managed AI Should Include

What you are actually buying

Most business owners encounter artificial intelligence as a simple subscription. One individual opens a chat window, pastes a draft, and receives assistance. This setup can be helpful, and nothing in this document argues against it. A managed AI service represents a different type of purchase. The buyer is not paying for access to a model. Instead, the buyer pays another party to take responsibility for a defined piece of AI work. This includes deploying the system, connecting it to the company's information and tools, keeping it running, answering when it breaks, and improving it over time.

This paper uses a working definition. Managed AI is an ongoing service where a provider takes responsibility for specified AI deployment, operation, maintenance, and improvement. The written scope determines exactly what is included. Managed private AI is managed AI with explicit controls over the company's information, access, processing environment, and permitted use. The second phrase is narrower, and the label alone proves nothing about it. The paper on what makes business AI private, which follows this one in the series, takes up that question directly.

Managed AI is a service label that more than one provider uses. Two providers whose public pages we inspected, Hyve and Infradapt, both use the phrase managed private AI for their own offerings [S6][S7]. Dominus Foundry, which publishes this research, develops Sabina, which it positions as managed AI and managed private business AI. That is a commercial interest and the reader should weigh everything here with it in mind. The way we have tried to earn the reader's trust is by making the evidence inspectable: every source is listed with the date it was retrieved, and the cited passages identify the evidence used for the analysis.

The practical consequence of the definition is simple. If you cannot point to the sentence in a proposal that says who does a task, you have not bought that task. The rest of this paper is a way to find those sentences before you sign.

Where managed private AI sits

It helps to place the purchase on a spectrum, because the right choice depends on how much responsibility you want to hand over.

Three ways to acquire business AI (illustrative framing, not a market survey)

Scroll the table horizontally if needed. Keyboard users can focus the table and use arrow keys.

Cloud computing has already taught buyers a crucial lesson about shared duties. Amazon Web Services frames security and compliance as a joint effort, where the provider safeguards the infrastructure while the customer’s obligations vary based on the specific services chosen. For instance, a virtual machine service places the burden of maintaining the guest operating system and its patches squarely on the customer [S2]. Microsoft applies this same logic to generative AI. The company outlines three distinct layers: the AI platform, the AI application and AI usage. It clarifies that responsibilities shift depending on whether the integration follows a software as a service, platform as a service, or infrastructure as a service model [S1]. Regardless of the purchase, a portion of the responsibility remains with you. The critical questions are how significant that share is and whether the contract explicitly defines it.

Another aspect of the Microsoft guidance warrants attention because it challenges typical service provider interests. The company advises organizations to start with software-as-a-service approaches for their initial AI adoption. This strategy minimizes the level of responsibility and technical expertise the organization must provide. Microsoft suggests that building custom models is best reserved for organizations with deep expertise [S1]. A managed service offers a practical way to achieve this reduction in responsibility. It allows you to avoid the burden of complex infrastructure management without restricting your options to off-the-shelf products. This approach balances operational control with strategic flexibility.

What "managed" should include

A managed service is only as good as its scope. Reading two providers' public descriptions side by side shows how differently the same phrase can be filled in, and why the matrix later in this paper is worth using.

Hyve describes managed private AI as dedicated infrastructure, deployed and managed by Hyve. It lists what it manages: architecture and sizing, platform deployment, security and access design, monitoring and maintenance, backup and recovery, and capacity planning. It also offers a multi-tenant option with logical isolation between workloads, and AI on Microsoft Azure, alongside the dedicated option. This shows that even one provider's page does not treat "private" as a single arrangement [S6]. Infradapt describes a service that is self-hosted by default, single-tenant and vendor-independent. It is delivered for one fixed monthly fee. Its list of inclusions goes further into the business side: readiness assessment and use-case selection, usage policy design, role-based access, audit logging, staff onboarding and training, monitoring and tuning, and governance reporting for leadership and auditors [S7].

These are vendor descriptions of their own offerings. They are not independent evidence that the services perform as described, and this paper does not treat them that way. They are useful for a different reason: they show the range of what a provider can put under the word "managed." One scope ends at the platform. Another reaches policy, training and reporting. A buyer who assumes the second when the contract says the first has bought less than they believe.

From these sources and the shared-responsibility literature we derive seven areas a buyer should expect a scope to address. This is our synthesis, not a standard, and a provider's scope may reasonably divide the work differently.

Setup

Setup covers deciding which use cases to start with, which information the system may use, and how the environment is configured. Infradapt lists a readiness assessment and use-case selection as the first step before anything is deployed [S7]. Ask who chooses the first use cases, who signs off on the data connected to them, and what "done" means for setup.

Integrations

Connecting AI to company systems is where much of the practical value, and much of the risk, lives. Hyve describes retrieval-augmented generation, where applications retrieve relevant material from approved sources to provide context to models. This process involves applying access controls during retrieval and refreshing source information as business needs evolve [S6]. Buyers should ask which systems are connected, who maintains each connection when changes occur, and how the service handles broken connections.

Access

Access is two questions: who may administer the service, and who may use it and see what. Hyve names data location, access control, network separation and data handling as the areas where private AI depends on more than dedicated hardware [S6]. Infradapt lists role-based access controls and encrypted data storage [S7]. Ask who can add or remove users, how access to connected information follows the person's existing permissions, and who at the provider can see your information.

Monitoring

The NCSC guidelines position logging, monitoring, and update management within secure operation and maintenance, the fourth lifecycle stage following design, development, and deployment [S5]. Infradapt includes audit logging and usage tracking in its standard offerings [S7]. When evaluating a provider, ask specifically what data is recorded, who accesses those logs, how long records are retained, and what information you receive routinely without needing to request it.

Support

Support is worth pinning down in writing. Ask for response expectations, who answers, what counts as an incident, and how you are told when something has gone wrong. Microsoft's guidance notes that user behavior and accountability need more emphasis in AI systems, and that acceptable use policies and staff education matter [S1]. Check whether training your own people is in scope or assumed.

Improvement

Managed services promise ongoing improvement, so the scope should define what that means: model changes, prompt and workflow updates, new integrations, and quality evaluation. The NIST Generative AI Profile notes that outputs can be wrong in ways that are hard to attribute to one component when many third-party parts are involved [S4]. This complexity is one reason, in our reading, that a change process and a way to test changes matter [S4]. Ask how changes are tested before they reach you, and who approves them.

Exit

Exit is easy to leave out of a proposal, so ask about it explicitly. Ask what you take with you at the end: documents, indexes, conversation records, configuration, and anything the system accumulated about your business. Ask in what form, within what time, and what the provider deletes afterward. For a full exit review, examine company knowledge, memory and portability together.

The responsibility matrix

The table below is the practical output of this paper. The matrix shows what a proposal should be able to show. Then use the worksheet after it to record, for each row, what the proposal actually says, where it says it, and who owns the follow-up, working from the provider's written proposal rather than from conversation. A row you cannot fill from a document is a question to send back.

Responsibility matrix for a managed AI proposal

Scroll the table horizontally if needed. Keyboard users can focus the table and use arrow keys.

Worksheet: record what the proposal says

Scroll the table horizontally if needed. Keyboard users can focus the table and use arrow keys.

How to score a proposal

Score each row on three levels: written and specific, written but vague, absent. If two or more of the setup, access and exit rows are absent, that is a reason to ask for a revised proposal before comparing prices. The score is a conversation tool, not a measurement. It tells you where the proposal is thin, and it does not tell you whether the service will work.

A worked illustration

The following is an invented example for illustration, not a customer story and not a result. A regional contractor wants an AI service that answers staff questions about open jobs using the company's job records and email. The contractor reads three proposals against the matrix.

Proposal A lists a platform, a model and a monthly fee. Setup, integrations and exit are silent. Proposal B names the systems it will connect and who maintains each connection, describes role-based access that follows existing permissions, and provides monthly usage reports, but says nothing about exit. Proposal C is similar to B and adds an export of documents and indexes in a stated format on request.

The matrix does not choose between B and C by itself, since C might cost more or connect fewer systems. What it does is turn an apparent tie on features into a visible difference: only one proposal answers the question of what the contractor holds if the relationship ends. It also exposes that Proposal A is not comparable yet. The honest response to A is to ask for the missing rows, not to guess at them.

Risks the scope must cover

A scope that lists tasks without naming the underlying risks is incomplete. The NIST AI Risk Management Framework is a voluntary framework intended to help organizations incorporate trustworthiness considerations into the design, development, use and evaluation of AI products and services [S3]. NIST's Generative AI Profile, released in July 2024, identifies risks unique to or exacerbated by generative AI and proposes actions to manage them [S4]. It lists twelve risk categories. Several of these bear directly on what a managed service must handle.

• Data privacy, including leakage and unauthorized use or disclosure of information [S4].
• Information security, which NIST treats as its own risk category [S4]. In a managed service, our reading is that it becomes a task divided between provider and buyer, which the matrix is meant to make explicit.
• Human-AI configuration, which includes over-reliance on AI output and the misconfiguration of systems by the people using them [S4].
• Value chain and component integration, since a generative AI system often depends on third-party components and data sources, and it can be difficult to attribute an issue to any one of them [S4].

Citing a framework does not prove that a provider follows it. Any claim of alignment requires independent evidence. The NCSC guidelines for secure AI system development, version 1.0 published 27 November 2023, offer a second public reference. They organize secure AI system development into design, development, deployment, and secure operation and maintenance. These guidelines prioritize taking ownership of security outcomes for customers [S5]. Buyers can ask providers which stage each practice belongs to and who owns it.

When a simpler option is enough

A managed service adds cost and a relationship to manage. It is not the right answer to every need. If the main use is occasional drafting and summarizing by individuals working with material that is not sensitive, and where applicable regulations and contracts permit the use, an ordinary subscription with a clear acceptable use policy may be adequate. The vendor's own guidance leans the same way for early adoption [S1].

A managed service starts to merit evaluation when the work is coordinated rather than individual: when the AI needs the company's context and defined permissions, when several people depend on it, when someone must be accountable for keeping it running, and when the company lacks the staff to operate it. Even then, a pilot on one or two use cases, with the matrix filled in and an exit plan written down, is a more reasonable first step than a broad commitment.

What to take away

Treat "managed" as a list of named tasks, not an adjective. Seven areas, from setup to exit, give a buyer a way to read any proposal. The two inspected vendor pages show that scopes differ widely [S6][S7], and the cloud shared-responsibility literature shows that some responsibility always remains with the customer [S1][S2]. Fill in the matrix from documents, send back the blank rows, and compare proposals only after each answers the same questions.

Limitations

• This paper rests on seven public documents from six organizations, retrieved on the dates listed in the references. Two of them are vendor descriptions of their own services: they show what providers say, not what they deliver.
• The shared-responsibility documents describe cloud and AI platforms from two large providers. How they apply to a small managed service is our interpretation.
• The seven areas in the matrix are our synthesis, not a published standard, and the worked illustration is invented.
• We did not interview buyers, measure outcomes or test any provider's service, and we make no claim about cost savings or results.
• Product pages change. The evidence cutoff is the date after which no new source was consulted.
• Dominus Foundry publishes this paper and develops Sabina, so the paper may reflect that interest despite our efforts to cite a source for each factual claim.
• This first edition is open for reader review. Check the current provider terms before relying on any vendor statement.

References

1. Microsoft, Artificial intelligence (AI) shared responsibility model (Primary vendor documentation; 2026-08-24 (page last updated)). Accessed 2026-10-20.
2. Amazon Web Services, Shared Responsibility Model (Primary vendor documentation; undated page). Accessed 2026-10-20.
3. NIST, AI Risk Management Framework (Primary standards body page; AI RMF 1.0 released 2023-01-26; page references 2026-04-07 update). Accessed 2026-10-20.
4. NIST, NIST AI 600-1, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (Primary standards body publication; 2024-07). Accessed 2026-10-20.
5. UK National Cyber Security Centre, Guidelines for secure AI system development (Primary government guidance; 2023-11-27 (version 1.0)). Accessed 2026-10-20.
6. Hyve, Managed private AI hosting (Vendor description of its own offering, not independent proof of performance; undated page). Accessed 2026-10-20.
7. Infradapt, Managed private AI for business (Vendor description of its own offering, not independent proof of performance; undated page). Accessed 2026-10-20.

Contributors and disclosure

Dominus Foundry (publisher; develops Sabina and has a commercial interest in managed AI); Drafting: Claude-assisted manuscript, with selected prose revised by Clio's approved internal model and edited by Dominus Foundry.; First edition. Published for reader review.

Published by Dominus Foundry, creators of Sabina. This publication has a commercial interest in managed AI.