Where Portainer AI shows up in enterprise conversations
The three products each answer a specific conversation happening on CIO and CISO desks right now. Read the scenario that matches yours; the fix is a briefing away.
Your people are building AI apps on someone else's cloud
What is happening
A department head opened a ChatGPT or Claude account and had it build the tool they wanted. The tool runs on the AI provider's hosting, reaches back into your data, and works well enough that the department will not give it up. This is happening across the business, faster than anyone can track. IT does not know what is running or where.
Banning it is not the answer. The activity is real and useful, and the ban only sends it further underground. What is missing is a sanctioned place for that activity to land, one that gives the department the same low-friction experience and gives IT visibility and control.
A governed place to run
An MCP endpoint the AI tool the department already uses can deploy to. An isolated Kubernetes namespace per app, on infrastructure you own. Every deploy committed to your Git. Business users see an app URL, not a cluster.
See Portainer-Run →Your engineers use AI agents against production with their own credentials
What is happening
Developers are running Claude Code, Cursor, Codex, and similar tools against real environments, with the developer's own kubeconfig plugged in. The agent gets full write access to whatever the developer can reach. When something breaks it is hard to trace: the audit trail says the human did it, because the credential was theirs.
The CISO cannot see any of this. There is no policy layer, no per-environment control, no way to allow AI in dev clusters but block it from production, and no way to stop a runaway session before it does damage.
A control plane between agent and cluster
Read-only sessions with rationale and TTL. Every change as a human-approved GitOps pull request. Per-environment controls, full audit across every agent, and one-click emergency halt.
See Portainer-Command →Your AI agents cannot see the documents you already own
What is happening
The organization has decades of unstructured documents (policies, engineering records, scanned files, reports) sitting in file stores. The AI agents your teams are experimenting with answer from training data, because they have no way to see any of the corpus. The two conventional answers each cost something you would rather not spend.
A cloud RAG service takes the corpus outside your boundary, which the security team will not sign off on. Building the pipeline in-house means procuring GPU capacity for a workload most of your organization does not think about. Meanwhile your organization already owns hundreds of workstations that do nothing between 19:00 and 06:00.
Turn idle workstations into private retrieval
A self-hosted appliance that harvests idle workstations overnight to OCR and embed your corpus, and serves a private, citable retrieval endpoint any agent can query. Documents never leave your bucket. Retrieves, never generates.
See Portainer-AiGrid →Standing up a governed AI operating model, not just responding to fires
What is happening
The CIO is being asked, by the board or by regulators, to describe how the organization operates AI. Not "which AI vendors do we use" but "what is the model for building, running, and governing AI inside this enterprise". Any answer smaller than the three problems above will not stand up.
The end-to-end answer is one operating model built on one control plane, with three product surfaces, one identity model, and one GitOps source of truth. Apps land in Run. Agents operate through Command. Both draw on the corpus AiGrid indexes.
The direct answer
All three Portainer AI products share the same Portainer Business control plane, the same RBAC, and the same GitOps repositories. There is no seam between them for a CIO to explain to a board or a regulator, and no additional infrastructure to procure for each new AI conversation that lands.
Portainer-Run
Governed place for staff-built AI apps to land, with an MCP endpoint the tools they use can deploy to.
Portainer-Command
Governed AI agent access to the same clusters, with human-approved GitOps as the only write path.
Portainer-AiGrid
Governed retrieval over the corpus you own, on infrastructure you already run.
Use case questions, answered directly
Do most organizations start with all three, or one?
One. The most common pattern is that a CIO buys the product that maps to whichever conversation is loudest that quarter, and adds the others as those conversations come up. The three share a control plane, an identity model, and a GitOps source of truth, so adding the second and third is easier than standing up the first.
Do we need to already run Portainer Business?
No. Portainer Business is included with every Portainer AI product's license, and can be stood up as part of the installation. If you already run Portainer Business 2.44 or later, the AI products install as add-ons from inside the UI.
Which scenario should we run first?
Whichever of the three matches the AI conversation currently landing on your desk hardest. If shadow AI apps are the pressure, start with Run. If agent access to production is what your CISO is asking about, start with Command. If the "why can't the agent answer from our documents" question is coming up, start with AiGrid.
Tell us which scenario matches yours
We will walk through the product that maps to your current AI conversation on a live governed Kubernetes environment, and show what standing it up in yours looks like.