# Private AI is not one architecture. > When an organization asks for its own AI, the words can conceal several different requirements. Some teams want company knowledge in an approved assistant. Others need strict retention controls, a private network path or the ability to run inference entirely within infrastructure they manage. The answer should be determined by those constraints, not by a fashionable diagram. Canonical URL: https://marmation.com/solutions/private-enterprise-ai/ ## The decision Which information must stay where, and who may use it? Decide whether the requirement concerns training, retention, processing location, network access or running the model yourself. Compare deployment options against those requirements and the work needed to operate them. ## Employees need answers while IT must control the information Imagine a manufacturer with years of internal service documents, role-specific procedures and employees across regions. Staff want reliable answers, but IT needs permission-aware retrieval and clarity about where content flows. A product that answers questions but ignores document revocations is not an enterprise solution. ## Neither self-hosting nor an enterprise API solves every requirement “Self-host everything” can be unnecessary and expensive. “Just connect ChatGPT” may fail data-handling or identity requirements. Even an enterprise API is not the complete application: sources need indexing, citations, updates, authorization and evaluation. The architecture must define what the model can see and whether it can take actions. ## Turn privacy requirements into a deployment comparison Write down the actual restrictions: whether submitted data may be used for training, how long copies may remain, who may read them and where processing may occur. Include network, audit and operating responsibilities. Map the permitted information flow and compare existing enterprise tools, managed model APIs, controlled cloud services and licensed self-hosted models. The recommendation should explain both the control gained and who must keep it working. ## The evidence needed for a private AI decision - Requirements and data-flow assessment covering identity, data classification and deployment restrictions. - Evaluation of managed enterprise services against custom integration and self-hosting options. - A focused working test using approved or sample data, including attempts by users who should be denied access. - Architecture, operating cost, reliability and handover documentation. ## Different privacy requirements lead to different designs A private network endpoint does not necessarily mean a privately owned model. A fine-tuned model is not a replacement for current documents. A self-hosted model may provide additional control, but its inference, updates, guardrails and uptime still have to be operated. The right design may be a small custom app around an existing approved platform. ## Test removed access, retired documents and the handling of logs Test authorized and unauthorized users, changed group membership, retired documents, malformed uploads, missing citations and model failure. Validate logging and retention against documented policy, not a marketing assurance. Review source-permission synchronization and specific preview/GA features in the chosen stack. ## Compare options before commissioning a new platform A private AI architecture decision sprint should produce an option matrix, security questions, a first reference workflow and an honest cost estimate. If the existing enterprise tool solves it, recommend configuring it instead. ## Related reading - [Make AI work with the systems your business already runs.](https://marmation.com/solutions/enterprise-ai-systems/) - [Retrieval cannot be allowed to widen a user's permissions.](https://marmation.com/expertise/permission-aware-rag/) - [Private AI doesn't mean training your own model.](https://marmation.com/review/private-ai-does-not-mean-owning-a-model/)