What Are the Different AI Platforms?

Overview

“AI platform” does not name one product category. It can mean an application people use directly, a model API developers call, a cloud service for building and operating models, a hub for sharing downloadable models, or software for connecting models to business workflows. Many products combine several of these roles. There is no stable, exhaustive list of “all” AI platforms: products, model catalogs, and brand names change frequently. A useful answer is to distinguish the layers and choose by task, control needs, integration, and operating constraints.

The examples below are representative rather than ranked. They describe product types, not a claim that one provider is best. Vendor documentation establishes what a provider says its own service offers; it does not establish comparative quality on a particular user’s work.

What an AI platform is

An AI platform is a software environment that provides some combination of access to AI models, data preparation, development tools, deployment, and ongoing management. A broad lifecycle platform may bring those functions together; a narrower AI product may provide just an interface or an API. Microsoft’s general description, for example, includes data ingestion, model training, application and agent deployment, and monitoring, while also recognizing cloud, on-premises, and hybrid deployment options (What is an AI platform? | Microsoft Azure).

In this context, a model is the component that infers an output from inputs; a platform is the surrounding product or service through which people access, configure, combine, operate, or govern models. An AI system can produce predictions, content, recommendations, or decisions, according to the OSAID FAQs – Open Source Initiative. One model can be made available through multiple platforms, and one platform can expose models from multiple providers. For example, Amazon Bedrock offers a range of providers’ foundation models through a managed service, while Amazon SageMaker AI supports building, training, and deploying machine-learning and foundation models (Amazon Bedrock; What is Amazon SageMaker AI? - Amazon SageMaker AI).

The diagram is a conceptual view, not a required architecture. Some products provide most layers; others supply one component. Model output may need human review, especially before consequential decisions or external actions.

The main types of AI platforms

The categories below answer “what AI platforms are there?” by function. They overlap: a user-facing assistant can also be a developer platform, and a cloud provider can host both its own and third-party models.

1. AI assistants for direct use

ChatGPT, Claude, and Google’s Gemini app are consumer or workplace applications: people interact through a browser, desktop, or mobile interface rather than building an application from an API. They can support general questions and content tasks, and their feature sets may include files, web access, coding, or connected tools. For instance, OpenAI describes ChatGPT as a place to chat, work, and code (Overview | ChatGPT); Anthropic describes Claude’s product as supporting connected tools and editable work products (Claude | The AI assistant for work); and Google describes the Gemini mobile product as an AI assistant (Google Gemini). These are product descriptions, not independent performance comparisons.

An assistant is usually the simplest choice when a person needs help directly and does not need to embed the model in a separate product. A subscription interface should not be confused with developer access: API access, usage limits, privacy terms, model availability, and billing may differ from those of the consumer application.

2. Model APIs and provider platforms

An API platform lets software send prompts or other inputs to a model and receive outputs. Developers can then add the interface, data permissions, business rules, and user experience around it. Modern model APIs may also support tools: the model can request a function or a built-in service, and software or the provider executes it. OpenAI documents tools such as function calling, web search, file search, and computer use (Using tools | OpenAI API). Anthropic documents a related pattern for Claude: the model returns a structured tool request, which either the developer’s application executes or Anthropic runs when it is a server-side tool (Tool use with Claude - Claude Platform Docs).

Google’s Gemini API similarly documents built-in tools such as Google Search, code execution, URL context, and file search, as well as custom function calling (Using tools with Gemini API | Google AI for Developers). This illustrates a key distinction: a model call generates an output, while tool orchestration allows the application to retrieve information or initiate an action. Tool access must be explicitly configured, and developers remain responsible for validating results and controlling what actions are permitted.

Direct provider APIs are suitable when a team wants to build its own application around a provider’s models. Teams that expect to switch models should check model-specific request formats, tool support, rate limits, data retention, and evaluation behavior; a common API shape alone does not make a complete application portable.

3. Cloud and enterprise AI platforms

Cloud platforms combine managed compute with services for model discovery, training or customization, deployment, data connections, security, and operations. They are more than chat interfaces and APIs; their value is in managing a broader development and production lifecycle.

• Amazon Web Services: SageMaker AI is a managed service for building, training, and deploying models. Amazon Bedrock is a separate managed service for building generative-AI applications with a choice of foundation models, model evaluation, retrieval-augmented generation (RAG), and agents (What is Amazon SageMaker AI? - Amazon SageMaker AI; Amazon Bedrock). They serve related but distinct needs: SageMaker AI supports model-development workflows, while Bedrock emphasizes access to foundation models and generative application components.
• Microsoft: Microsoft Foundry groups model access, agents, and tools with management capabilities such as access controls, networking, and monitoring. Its documentation distinguishes a prompt agent configured through the portal from a hosted agent built with custom code (What is Microsoft Foundry? - Microsoft Foundry | Microsoft Learn).
• Google Cloud: Gemini Enterprise Agent Platform, described by Google as an evolution of Vertex AI, brings model access, agent development, deployment, governance, and evaluation together. Its Model Garden includes Google, third-party, and open models (Agent Platform overview | Gemini Enterprise Agent Platform | Google Cloud Documentation). Product naming has changed; older material may still refer to Vertex AI.
• IBM: IBM watsonx provides a generative-AI and machine-learning development environment alongside data and governance capabilities. IBM’s documentation describes building with code-based, automated, and visual tools, and managing lifecycle and governance functions (Overview of the watsonx experience).

These platforms can reduce the need to operate training and serving infrastructure directly, but “managed” does not mean maintenance-free. Organizations still need to configure identity, access, data connections, evaluation, monitoring, and fallback behavior. Feature availability and service boundaries can vary by region, account, model, and release stage.

4. Model hubs and open-model ecosystems

A model hub is a repository and collaboration environment, not necessarily a single model or a complete production service. The Hugging Face Hub organizes models, datasets, and demonstration applications called Spaces, and offers features for private collaboration as well as public sharing (Hugging Face Hub documentation · Hugging Face). A hub helps teams find artifacts and related information; it does not guarantee that each model is accurate, secure, maintained, or suitable for a given deployment.

“Open” also needs precision. Publicly downloadable weights do not, by themselves, prove that an AI system meets the Open Source Initiative’s definition. The OSI definition describes an open-source AI system in terms of the necessary code, data, and parameters being available under qualifying legal terms (OSAID FAQs – Open Source Initiative). Before using a model, inspect its model card, license and use restrictions, documentation, provenance information, and any dependencies. Requirements differ among models.

5. Local runtimes and self-hosted platforms

Local runtimes download and execute compatible models on a user’s own machine or managed hardware. Ollama, for example, documents both local execution and an optional hosted-model route; its documentation warns that local speed depends on hardware and that large models can be slow without a capable GPU (Download Ollama on macOS). Local inference can keep the request-processing step on controlled hardware, but this does not automatically make a workflow private or secure: logs, connected applications, downloaded model files, network access, and user permissions still matter.

Self-hosting may suit teams that need control over the serving environment or want to use particular open-weight models. The trade-off is responsibility for compute capacity, updates, security patches, model serving, monitoring, and performance under load. “Runs locally” is a deployment description, not a guarantee of model quality, legal permission, or protection from unsafe output.

6. Workflow, agent, and specialist platforms

Workflow and agent platforms connect a model to other steps: retrieving company documents, calling application APIs, writing to a database, or asking a person to approve an action. In a basic retrieval-augmented generation (RAG) workflow, software retrieves relevant records and supplies them as context for a model response. In an agent workflow, the model may select among permitted tools and repeat actions until a defined task is complete. The model itself does not grant authority to act; the surrounding application and its permissions determine which operations can run.

Cloud services increasingly include agent development and evaluation features. Microsoft Foundry describes prompt agents and custom hosted agents; Google’s Agent Platform documents agent runtimes, tool gateways, evaluation, and observability (What is Microsoft Foundry? - Microsoft Foundry | Microsoft Learn; Agent Platform overview | Gemini Enterprise Agent Platform | Google Cloud Documentation). These examples show that “AI platform” can refer to the orchestration and operations surrounding models, not only model training.

Task-specific platforms embed AI inside an established activity. Adobe Firefly is an example in creative work, with generative image and video workflows and integration with Adobe products (Adobe Firefly overview | Firefly). GitHub Copilot is a coding-focused assistant integrated into software-development workflows (What is GitHub Copilot? - GitHub Docs). These products may reduce context switching for a specialized task, while being less suitable as general-purpose infrastructure for unrelated applications.

How the types fit together

The following is a practical stack, not a rule that every system must use every layer. An individual might use only an assistant. A software company might use a provider API plus its own retrieval, access controls, and user interface. An enterprise might select models through a cloud platform and add local data connections, workflow tools, and human review.

A platform may bundle several layers, but components are not interchangeable merely because they share a brand. For example, a cloud foundation-model API and a machine-learning training environment address different parts of the stack. Likewise, a model hub helps locate models but is not necessarily the service that hosts them for production traffic.

How to choose an AI platform

Start with a defined task rather than a brand list. The best platform for summarizing a small set of documents may be a ready-made assistant; an application serving customers at scale may need APIs, retrieval, access controls, monitoring, and a deployment environment. For predictive modeling on structured business data, a full ML lifecycle service may matter more than a conversational product.

A selection process

1. Specify the job and failure cost. Describe the inputs, desired output, users, action permissions, and what errors would cost. Separate low-risk drafting from decisions that affect money, health, employment, legal rights, or access to services.
2. Test representative examples. Use a held-out set of real or carefully constructed tasks, including difficult cases. Measure task accuracy, citation or source correctness where relevant, completion rate, response time, and the amount of human correction. NIST’s generative-AI profile advises evaluating capability claims empirically and measuring performance in conditions similar to deployment (Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile).
3. Check data and security controls. Establish what the service receives, stores, logs, or shares; the allowed region and retention; whether the data may be used for training; identity and access controls; and how secrets or personal data are protected. Check current contract terms rather than assuming one provider’s consumer and enterprise settings are the same.
4. Estimate the operating model. Compare total costs, including model use, storage, retrieval, network traffic, monitoring, engineering time, and any hardware needed for self-hosting. Confirm regional availability, quotas, and the specific model versions required.
5. Assess operation and exit. Determine how you will monitor quality and changes, handle an outage or model retirement, export prompts and data, and replace a provider if needed. A platform’s integrated features can simplify operations but may tie workflows to its tools and formats.
6. Run a limited pilot, then review. Start with narrow permissions and human approval for consequential actions. Expand only after the system meets the evaluation and operational thresholds set for the use case.

This decision path is a starting point. Many projects combine categories; the final choice depends on the task and constraints rather than category labels alone.

Risks, limitations, and trade-offs

Output quality is task-dependent

A model’s general reputation or a vendor’s benchmark does not guarantee performance on a particular organization’s documents, languages, edge cases, or workflow. Generative systems can produce plausible but incorrect answers, and tool use can introduce errors in retrieval, tool selection, or action execution. NIST recommends empirically evaluating claims and reviewing source citations where systems rely on them (Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile). Human review is especially important where errors have material consequences.

Data protection is an operational property

Data exposure depends on the complete path through the application: the model service, logs, retrieval index, third-party connectors, and staff access. Hosting a model locally changes one part of that path, but the surrounding software and devices still need controls. Conversely, a cloud provider’s security features do not by themselves establish that a particular configuration or contract meets an organization’s requirements. NIST’s profile calls for risk assessment and ongoing monitoring of third-party generative-AI components, as well as attention to privacy, security, intellectual property, and component integration (Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile).

Convenience can create dependence

An integrated platform may offer one place for model selection, identity, deployment, evaluation, and monitoring. Those integrations can save implementation effort. They can also make an application depend on provider-specific agent formats, data stores, policy systems, or APIs. Using a multi-model gateway or a nominally common API can reduce some switching work, but it does not automatically move prompts, evaluation sets, permissions, retrieved data, or workflow logic. Portability should be tested, not inferred from marketing terms such as “open” or “interoperable.”

Open weights and self-hosting have their own costs

Downloadable weights can enable local operation and customization, but “open weights” is not synonymous with unrestricted use or fully open-source AI. License terms, acceptable-use provisions, training-data disclosures, and model documentation vary. Self-hosting also shifts capacity planning, updates, reliability, and security responsibilities to the operator. Evaluate these costs alongside cloud use rather than treating local execution as automatically cheaper or safer.

Governance continues after launch

The NIST AI Risk Management Framework is intended to help organizations incorporate trustworthiness into the design, development, use, and evaluation of AI products and systems; its generative-AI profile identifies additional considerations for generative systems (AI Risk Management Framework | NIST). In practice, platform selection should include a plan for monitoring drift or failures, responding to incidents, reviewing outputs and permissions, updating models, and retiring systems safely. Built-in guardrails and dashboards can support this work, but they do not replace an organization’s own risk ownership and testing.

The direct answer

The main kinds of AI platforms are ready-made assistants, model APIs, cloud AI development and deployment suites, model hubs, local model runtimes, agent and workflow builders, and task-specific AI applications. Common examples include ChatGPT, Claude, and Gemini for direct use; OpenAI, Anthropic, and Google model APIs for development; AWS, Microsoft, Google Cloud, and IBM enterprise services for managed AI workloads; Hugging Face for model and dataset sharing; Ollama for local or hosted model execution; and Adobe Firefly or GitHub Copilot for specialized creative and coding work.

No short list can name every AI platform or establish a universal winner. The useful distinction is what each platform provides and who operates each part of the system. Choose by testing the platform on the actual task and verifying data handling, cost, deployment, permissions, maintenance, and the practical ability to change providers.