Your data, your perimeter

Private AI or cloud AI: what exactly are we talking about?

The vocabulary is fuzzy, so let us start by pinning it down. Cloud AI covers two distinct realities. First, the SaaS assistants — ChatGPT Enterprise, Claude Enterprise — where the vendor hosts everything and you consume a per-user service. Then the APIs, possibly served through your existing cloud — Azure for OpenAI, AWS Bedrock or Google Vertex AI for Anthropic — where you keep control of the application but inference stays with the provider. In both cases, your data travels outside your perimeter, protected by a contract and certifications.

Private AI likewise covers a spectrum. The most common case: open models — Llama, Mistral, Qwen, DeepSeek, Gemma — served from your own GPU servers or those of a national host, under your control. Your data never leaves your network perimeter. The extreme case: air-gapped, with no outbound connection at all, for the most sensitive industrial or sovereign environments.

Between the two sits a grey area worth knowing: the private cloud, or trusted cloud, where a third party operates dedicated infrastructure for you, with localisation and non-access commitments. This is not private AI in the strict sense — you depend on an operator — but it resolves many cases without paying the full price. Many organisations that believe they need on-premise in fact need this.

What the cloud really guarantees — and what it does not

Let us be precise, because this is where costly misunderstandings are born. What the enterprise offerings from OpenAI and Anthropic guarantee contractually: your data is not used to train the models, exchanges are encrypted in transit and at rest, retention is configurable by the administrator, SOC 2 Type II certifications are in place, and vendor staff access to your content is governed and logged. These are serious guarantees, and it must be said plainly: for the vast majority of a company's documents, they are enough.

What they do not guarantee: that your data stays physically within your country — regional residency exists on some offerings, but rarely in Morocco; that no foreign judicial order can reach the host; that you keep control if the provider changes its terms. These are residual risks, low in probability, but not nil and not contractually removable.

The question to ask, then, is not "is the cloud secure?" — it is, in the sense of information security — but "what residual risk does my organisation accept, for which data?". An HR file, a sales quote, a briefing note: the residual risk is acceptable and the value of use is immediate. An industrial secret, a defence-related record, a named patient file: the answer changes, and that is where private AI enters the scene.

The three-year TCO: what each scenario really costs

The total cost of ownership is the most misused argument in the debate, in both directions. Rather than announce a figure that would be wrong for most readers, let us set out the line items to add up over three years: yours will depend on how many people you equip, your volumes and your negotiation.

SaaS cloud scenario: enterprise licences billed per seat per month — several tens of dollars per seat by the market's orders of magnitude, on quotation and tapering with volume — plus deployment support in the first year. Predictable cost, no upfront investment, capabilities always up to date. A sizing tip: multiply by the number of genuinely active seats, never by total headcount. API scenario: billed by volume — on the order of 1 to 5 dollars per million input tokens and 10 to 25 for output on the frontier models, per the public price lists of July 2026, five to ten times less on the lightweight variants. Variable cost, highly optimisable through caching, routing and batch processing.

Private AI scenario: this is where projections most often go astray, because only the hardware gets counted. The GPU line item — purchase amortised over three years, or rental — is only the visible part of the real cost, and rarely the heaviest. The rest splits between the initial engineering (architecture, RAG, serving, evaluation: two to four months of a team), ongoing operations (monitoring, updates, incident handling: a fraction of a role, never zero), and hosting (power, redundancy, backup). Our rule of thumb: private AI becomes competitive on TCO from several hundred active users, or from massive, repetitive API volumes — below that, it is justified by the data constraint, not by economics. Our AI cost calculator lets you simulate your configuration in dollars and in dirhams.

The skills needed to operate a private AI

This is the line item projections forget, and the leading cause of failure in the sovereign AI projects we audit. Serving an open model in production is not just launching a container. It takes, at minimum, four families of skills.

Inference engineering: choosing the model format and quantisation, sizing the server, configuring throughput and latency, managing queues and scaling. This is neither classic systems administration nor data science — it is a recent trade, scarce on the Moroccan market as on the European one. Application engineering: the bare model is useless; you need the RAG, the connectors to internal systems, the guardrails, the interface. This part of the work is identical in the cloud, but in private it rests on no off-the-shelf building block.

Operations: monitoring answer quality, handling incidents, updating models — an open model is not frozen, its successors ship every quarter and you have to decide when to migrate, then re-evaluate. And security: hardening, access management, logging, penetration testing.

In practice, for an enterprise private AI platform, count on a team of two to four people at cruising speed, or an equivalent managed-services contract. It is perfectly affordable — but it must be decided with eyes open, not discovered in the sixth month. Our sovereign AI offering takes on precisely this operational share for organisations that do not want to build it in-house.

Compliance, sector by sector: banking, healthcare, industry, public sector

Compliance is the only argument that truly settles the debate, and it is not reasoned globally but sector by sector, and even data point by data point.

Banking and insurance. In Morocco, the processing of personal data falls under Law 09-08 and the formalities with the CNDP, with specific rules governing cross-border transfer. Bank Al-Maghrib's prudential requirements on outsourcing add obligations of control and reversibility. In practice: augmented office work moves to a governed cloud without major difficulty; named credit data, scoring models and sensitive market data call for a private enclave or, at the very least, robust anonymisation upstream.

Healthcare. Health data is the most protected category everywhere, and the most closely watched. Cloud use is conceivable for administrative and documentary tasks that carry no patient data. As soon as the patient record enters the perimeter, private AI or certified hosting becomes the rule rather than the exception.

Industry. The issue is not personal data but the industrial secret: designs, processes, production parameters, predictive-maintenance data. No regulation forbids it, but the intellectual-property policy of many groups does — and legitimately so. This is the natural ground for private AI, up to air-gapped on critical sites.

Public sector and operators of vital importance. The DGSSI directives govern the hosting and security of sensitive information systems. The trade-off is no longer contractual but doctrinal: private AI, national sovereign hosting, or exclusion from the AI perimeter.

Hybrid: the most common answer, and the most misunderstood

In the vast majority of our engagements, the answer is neither pure cloud nor pure private, but a deliberate hybrid architecture — and this is where the reasoning really plays out. The principle: classify your data into three circles, then set the sovereignty dial circle by circle, not globally.

Circle one, public or weakly sensitive data: SaaS cloud, with no qualms. Circle two, everyday internal and personal data: a governed enterprise cloud — offerings with a contractual commitment, a written usage policy, control of connectors, CNDP formalities in order. Circle three, critical data: a private enclave, on your servers or with a national host, using the open models that are enough for the task.

The classic mistake, the one that costs the most, is to over-specify: applying the constraints of circle three to the whole perimeter, as a general precaution. The result is predictable — an eighteen-month project, inferior capability for everyone, and an adoption rate that never takes off, while staff use their personal accounts on their phones. Shadow IT is the real data leak, and over-specification is its leading cause.

The symmetrical mistake is to under-specify: send everything to the cloud without classification, and discover the problem at the first audit. A well-run hybrid is not a soft compromise: it is the only architecture that gives each piece of data the regime it deserves, and each employee the tool they will actually use.