Evaluation guide

Self-hosted enterprise AI: what stays in your cloud?

A platform can run in your cloud while still calling a model or business service outside it. Before choosing a deployment, follow the data through a real task. The useful question is not only where the application runs, but what each component receives and who operates it.

Start with the workflow, not the hosting label

Choose a representative task: answer a policy question, prepare a quotation or update a business record. List the documents, user identity, prompts, model responses and tool results that the task uses. Decide which information is sensitive and which actions require human review.

This creates a concrete deployment requirement. An internal knowledge assistant and an agent allowed to change orders may need different access policies, logging and approval steps, even when both use the same platform.

Separate storage from model processing

Application databases, uploaded documents, search indexes and conversation history are storage decisions. A request sent to an external model is a processing decision. Hosting the first group yourself does not automatically keep the second group in the same environment.

For each model configuration, document the endpoint, information sent, applicable retention terms and who holds the credentials. A locally hosted model changes the operating responsibilities: your team must plan its serving capacity and maintenance. Neither arrangement is universally preferable; match it to your requirements.

Include tools, logs and supporting services

A connected business tool may receive selected conversation details or return sensitive records. Review its permissions, credentials and network destination. Test that an agent cannot obtain or change information outside the access intended for that user and workflow.

Also review traces, error reporting, backups and any licensing or telemetry connection. Logs can contain prompts and tool results. Ask what is captured, where it is stored, how it is redacted and who can inspect it. Treat an air-gapped deployment as a separate requirement to validate, not a synonym for self-hosting.

Make the operating responsibilities explicit

Agree who installs updates, manages secrets, backs up application state and responds to incidents. Identify the dependencies needed to restore service. Confirm what support can see and what access, if any, the supplier needs during troubleshooting.

Bring the deployment team into the evaluation before a contract is signed. A useful handover includes a data-flow diagram, an ownership matrix and a tested restore procedure. These are acceptance criteria for your environment, not claims that a generic product page can certify.

What to validate in a Pengui evaluation

Pengui is positioned as an enterprise AI platform deployed on your infrastructure, with a branded workspace and a choice of models and integrations. Evaluate those choices together: demonstrate a real task, inspect the allowed actions and trace the resulting information flows.

Ask the team to distinguish available capabilities, configuration work and any additional integration required for your project. Document the agreed model endpoints and data boundaries. Private deployment is useful when its responsibilities are understood; it is not a promise that no information ever crosses a network boundary.

A concrete acceptance exercise

Run the same task with an authorized user and a user who should not have access. Check the answer, tool behavior and retained records in both cases. Then repeat with a model timeout or disconnected integration and review how the failure is reported.

Finish by agreeing which records can be deleted, how backups are handled and who verifies the configuration after updates. The outcome should be a deployment decision supported by observed behavior and documented terms, not just an impressive demo.