Define the processing boundary.
Choose where models, the gateway, logs, and supporting services run. Review external tools and fallbacks as part of the same data policy.
Compare deployment options →Solutions / Private AI
Choose where your AI models and data are processed.
Run models on local hardware, your GPU servers, or infrastructure in your cloud account. Connect your tools through Cortega and apply policies for access, sensitive work, and approved fallback destinations.
Delivered through Cortega AI Border Gateway with private model infrastructure.
Private AI / What you can do
Private deployment is a set of practical choices.
Route each workload appropriately.
Send sensitive work to approved private endpoints and standard work to other eligible models. Set team access and approve fallback destinations explicitly.
Plan access and routing →Start with the workload.
Match model size, concurrency, and hosting cost to your team’s needs. Use dedicated rented GPUs for temporary capacity where provider hosting is approved.
Review hosting and operations →Deployment options
Four ways to run your models
The main decisions are where documents are processed, who operates the hardware, and whether you need continuous capacity or a temporary batch. The examples below describe possible fits; model quality and capacity depend on the workload.
| Option | Where it runs & how | Example workloads | Cost & responsibility |
|---|---|---|---|
| A. Local machine | A local open-weight model served by Ollama on a machine you control. | An individual or small-team pilot for coding, drafting, summarization, or document questions. | Uses available hardware. Memory limits model size and context; you maintain the machine and runtime. |
| B. Organization-owned GPU server | vLLM on an existing compatible GPU host, reached through your organization’s network. | Shared inference for sustained coding, research, and document-analysis workloads. | Hardware purchase or existing capacity, power, and operations. Your organization manages capacity, security, and updates. |
| C. GPUs in your cloud account | vLLM in a cloud environment you administer. Cortega’s provisioning scripts support AWS; other clouds use an existing compatible host. | Shared team access without buying a server, with network, region, and storage choices in your account. | Cloud compute, storage, and networking charges. You manage the account, access policies, and running resources. |
| D. Dedicated rented GPUs | Your selected model on dedicated capacity operated by a GPU rental provider. | Temporary capacity for a large research or document-analysis batch, where provider-hosted processing is approved. | GPU-hour billing while running, including idle time. Data leaves your infrastructure; provider location, retention, and terms matter. |
Options A–C keep inference in infrastructure you control when the gateway, stores, and auxiliary services are configured there too. Option D is dedicated capacity on a provider’s infrastructure. Dedicated hardware alone does not make it equivalent to an on-premises deployment.
Legal workflows
What the infrastructure enables for a firm
01
Sensitive drafting and research
Connect Claude Code or Codex through Cortega Legal. Mark sensitive work and configure its route to approved private endpoints. This gives the firm control over the inference destination and access policy.
Cortega Legal →02
Discovery batches
Use shared GPU capacity for document analysis, summaries, and relevance review. For occasional large jobs, approved dedicated rental capacity can avoid a hardware purchase. Running hours, queueing, and startup time affect the cost and schedule.
Discovery workflow →03
Source-backed review
Private hosting controls where inference runs; citation verification and document grounding check the answer. Add Cortega Legal checks and review the resulting evidence before using a draft or discovery finding.
Document verification →04
Shared capacity with accountability
Use team model access, usage records, and configured spending limits to manage firm-wide demand. Cortega Legal’s matter selection adds matter context to request records; it does not create per-matter budgets.
Matter context →Setup
From a model host to a legal workflow
01
Choose a model and host
Match model quality, document length, memory, and concurrent users to the work. Start Ollama locally, deploy vLLM to an existing server or your AWS account, or create a dedicated deployment with a rental provider.
02
Register the endpoint in AIBG
Add the provider and model, store its credentials in the gateway, and configure team access. Place AIBG and its data stores in the intended environment. Approve primary and fallback destinations explicitly.
03
Connect the tools
Use Cortega Legal for the legal VS Code workspace, Endpoint Guard to configure supported assistants, or client-specific gateway settings. Endpoint Guard’s separate app-inspection path still sends traffic to its original destination; it does not replace a SaaS model with a private one.
04
Test the actual workflow
Run representative documents, streaming requests, and tool calls. Check the selected model, failure routes, and captured data. Use Red Team to evaluate the chosen guardrails and model before rollout.
Red Team →Packages & operations
Separate model hosting from gateway management
Foundation
Connect self-hosted models and registered rented GPU endpoints to AIBG. Model routing, guardrails, MCP governance, observability, and cost tracking are included. Hardware and provider charges are separate.
Enterprise
Add rented GPU lifecycle controls: attach an existing deployment, start or stop it, stop idle capacity, and track estimated spend and limits. Creating, sizing, and deleting the deployment remains with the provider. Enterprise also adds platform access and operational controls.
Cortega Hosted is a separate hosted service offering; it is not a model installation in your own cloud account. Air-gapped operation is a separate deployment choice that requires local runtime dependencies, models, and services.
Compare packages →Architecture
Tools, gateway, and model hosts
Your tools call AIBG. The gateway identifies the caller, applies configured controls, and routes to an approved model endpoint. A deployment can use one option or several; every fallback must follow the same data policy as the primary route.
Keep inspection models, logs, backups, and verification services inside the intended boundary too. Web search, MCP tools, extensions, and external fallback models can send data elsewhere even when the main model is private.
Private AI
Plan your private AI deployment
Start with the documents, users, data-location requirements, and expected workload.