Buyer guide · Updated October 2026
Most AI products ask you to send your data to them. A custom build can run the other way round: the agent, the documents and the logs stay in your cloud account or tenant, and your security team reviews it like any other internal system. Here is what that actually involves.
Get a scoped estimateDirect answer
Yes. A custom AI agent or Private GPT can be deployed into your AWS, Azure or Google Cloud account, your Microsoft 365 or Google Workspace tenant, or on-premises hardware. Your identity provider controls who can use it, your storage holds the documents and logs, and the only data that leaves is the request sent to the model provider you approve, or none at all if you run an open-weight model inside the boundary.
What you give up is convenience: your team provisions the account, grants access and owns the cloud bill. What you get is that the system is yours, passes your security review on your terms, and keeps running if the vendor relationship ends. HummingAgent builds this way by default; the K3 Technology Private GPT deployment described in our case studies is one example.
Every deployment conversation should start with a one-page diagram of where data goes. For a Private GPT the usual answer is: documents in your storage, embeddings and search index in a database in your account, the application and its logs in your compute, user identity from your directory, and a request to the model endpoint for each question. The model endpoint is the one place data crosses a boundary, which is why its choice gets the most attention.
For an agent that takes actions, add the integrations to the diagram. Each one is a credential your system holds, scoped to the least access the workflow needs. Credentials live in your secrets manager, never in a prompt or a config file.
| Component | Where it lives | Who controls access |
|---|---|---|
| Source documents and records | Your storage (S3, Blob, SharePoint, Drive) or your databases | Your IT, through existing permissions |
| Search index and embeddings | A database in your account | Your IT; the application reads it |
| Application and review screens | Your compute (containers, serverless, or a VM) | Your identity provider (Entra ID, Okta, Google) via SSO |
| Logs and audit trail | Your logging service, with your retention policy | Your security team |
| Model calls | Provider endpoint you approve (Azure OpenAI, Bedrock, Vertex AI, Anthropic), or an open-weight model in your account | Contract terms and network rules you set |
| Integration credentials | Your secrets manager | Your IT; rotated on your schedule |
There are three realistic positions, and the right one depends on your data classification, not on preference.
Treat the agent like any new internal application and the review goes smoothly. These are the items that come up in nearly every review we have been through, and what we bring to each.
| Review item | What we provide |
|---|---|
| Data flow and classification | The one-page diagram, with each data class labeled and the model boundary marked |
| Identity and access | SSO through your directory; role-based access mapped to your existing groups; no local accounts |
| Secrets handling | All credentials in your secrets manager; no keys in code, prompts or configuration files |
| Logging and audit | Every request, retrieved source and action logged to your logging service with your retention policy |
| Prompt injection and misuse | Retrieval limited to sources the user already has permission to read; tools gated by allow-lists; high-impact actions require a person |
| Vendor terms | The model provider's data-processing terms, region and training-exclusion commitments, in writing |
| Incident response | Who is paged, how the system is disabled, and how a bad action is reversed, agreed before launch |
| Exit | You hold the code, the infrastructure and the data. Ending support with HummingAgent does not turn anything off |
Your side provisions and owns; our side builds and documents. Being explicit about this at the start is what keeps a deployment on schedule.
| Task | Your team | HummingAgent |
|---|---|---|
| Cloud account or subscription | Creates it, sets billing and guardrails | Specifies what is needed and why |
| Network and identity | Configures SSO, groups, private endpoints | Provides the integration requirements and tests them |
| Infrastructure as code | Reviews and approves | Writes it, hands it over with the repository |
| Application build | Supplies real examples and a reviewer | Builds, evaluates against the examples, documents |
| Security review | Runs it against your standard | Supplies the evidence listed above and fixes findings |
| Launch and monitoring | Owns the on-call path if you want it | Sets up dashboards and alerts; optional ongoing support |
Deploying in your own infrastructure changes the shape of the cost more than the size. The build fee is similar to a hosted build; the difference is some extra engineering for your environment and security review, which is why we ask you to decide on the deployment target at discovery rather than later. HummingAgent's planning ranges are $15,000 to $50,000 for a custom agent or integrated workflow and from $50,000 for multi-system builds; discovery starts at $2,500.
The operating cost moves onto your cloud bill: compute for the application, a database for the index, storage, logging, and model usage billed by your provider. For a Private GPT used by a small team this is typically a modest line item dominated by model calls; for a high-volume agent it is dominated by whatever the metered unit is, which is why we size it from your real volume. Ongoing HummingAgent support, if you want it, starts at $1,500 a month and is the only vendor fee.
A company AI workspace that answers from your approved documents and systems, runs under your access controls, and sends requests only to a model provider you approve, or to a model running inside your own infrastructure. It is private in the sense that your data, prompts and logs stay with you, not that the model was trained only on your data.
Not under enterprise terms from the major providers (Azure OpenAI, AWS Bedrock, Google Vertex AI, Anthropic), which exclude customer data from training. We put the provider's written terms in the security review package. If you run an open-weight model yourself, the question does not arise.
Yes, with an open-weight model on your own hardware. You take on the model infrastructure and updates. Most clients choose a provider endpoint inside their cloud perimeter instead, which keeps traffic private without operating GPUs.
You do. Client-specific code, infrastructure definitions and documentation are delivered to your repository. The statement of work also names any reusable HummingAgent components, third-party services and open-source dependencies so ownership is not ambiguous.
The system keeps running. It is in your account, under your identity provider, with your credentials. You take over monitoring and vendor bills, or hand them to another team.
It depends on how quickly your team can provision the account, grant access and schedule the security review. The build itself is scoped at discovery with milestones; the environment setup on your side is usually the critical path, so we start it first.
A discovery session produces the one-page data flow for your workflow, the model boundary your security team can approve, and a scoped estimate with your cloud costs itemized.
Schedule a discovery call