GPT Professional Services: Scoping a Real Deployment

You deployed this eighteen months ago. Nobody approved it.

Most companies buying GPT professional services are not starting from zero. They are starting from forty people with personal subscriptions, pasting customer emails and draft contracts into a consumer product on personal accounts, with no logging, no retention policy and no record of what left the building. The project is therefore not adoption. It is bringing an existing, unmanaged deployment under control, and that reframing changes what you should be buying: an architecture decision, an access model, and a cost model, in that order. The technology part is the easy third.

ChatGPT for business, and where the data goes in each option

Four ways to run this, and they differ far more in governance than in capability. The models underneath are close to identical in the first three.

• Consumer subscriptions on personal accounts. What you have now, whether or not anybody signed it off. No central visibility, no offboarding when someone leaves, no way to answer a client asking where their document went. Consumer and business tiers differ on whether content may be used to improve models, and the person who clicked accept was not your data-protection officer.
• A vendor business or enterprise tier. Central administration, single sign-on, workspace-level retention settings, and terms that exclude your content from training. This is the cheapest meaningful improvement available and most companies should do it in week one, before commissioning anything. It solves governance for general-purpose use and solves nothing for workflows.
• An application you build on the API. Your own interface or an integration inside the tools people already use, calling the model through a key you control. This is where retrieval over your own documents, permissions that mirror your existing roles, and audit logging become possible. It is also the only option where the AI can be embedded into a process rather than sitting in a separate tab.
• Open weights on your own infrastructure. Nothing leaves. Heavier to operate and rarely justified on cost alone, and the honest break-even is set out in self-hosted versus API.

Which of these you need is decided by the data class, not by company size. A fifteen-person law firm handling privileged material has a harder requirement than a four-hundred-person distributor drafting marketing copy. The reasoning behind that, and the questions a data-protection officer will ask, are in GDPR and LLMs.

Why a GPT deployment bill surprises people

Seat pricing is predictable and token pricing is not, and the move from the second architecture to the third is a move between the two. Three things drive the surprise, and all of them are design decisions rather than accidents.

Context is charged on every single call. A system that helpfully includes the last twenty messages, a policy document and three retrieved passages is paying for all of that every time somebody presses send. Trimming what goes into each call is the highest-return cost work available, and caching the repeated part of a prompt cuts its price substantially at every major provider, which is worth designing for rather than discovering.

Retries are invisible until they are not. A call that fails validation and runs again has been paid for twice. A pipeline with a retry on every step can double its own bill under conditions that look, from the outside, like the system working.

Anything agentic multiplies. One task that makes twenty model calls costs twenty times one that makes one, and a system permitted to decide its own steps can decide to take a great many. Spending caps per task and per day are not optional, and the reliability argument for keeping step counts low is in agents versus chatbots versus automation.

Model usage is still usually the smallest line in a build. It is simply the least predictable one, which is why it gets the attention. The rest of the money goes where it always goes, and the full cost breakdown puts integration and rollout well ahead of it.

Access control, audit logging and retention in an enterprise GPT rollout

Access has to mirror what you already have. If your document system says a junior cannot open the partner folder, an assistant that can quote from it has quietly removed that control. Permissions must be enforced at retrieval time, per user, not by instructing the model to be discreet. An enterprise GPT deployment that authenticates against your existing directory and filters what it can see per person is the only version of this that survives a security review.

Log the prompt, the retrieved sources, the output and the user. Not for surveillance. For the day somebody asks why the system said what it said, which arrives eventually and is unanswerable without a record. Keep the logs where your other logs live, with the same retention rules, and decide explicitly how long: indefinite retention of every prompt is its own liability.

Retention has to be set on purpose at three levels. What the provider keeps, what your application stores, and what ends up in your own logs. Companies configure the first, forget the second and are surprised by the third. The WA Center platform is a reasonable picture of the finished shape: several distinct user roles, permissions that decide what each one sees, and an audit trail, across four countries. None of that is AI-specific engineering, which is the point. Our other case studies carry the same layer.

What to do in what order

Buy the ChatGPT for business tier first, this month, and turn off the personal accounts. It is the cheapest governance you will ever purchase and it stops the bleeding while you think. Then find the two workflows where the general-purpose tool is being used as a stopgap for something that should be automated, because those are the ones worth building, and everything else can stay in the chat window permanently. Then build one of the two, measure it, and use the result to decide about the second. Whether your data supports either is worth checking before you commit, which is what the readiness checklist covers.

Four cases where GPT is the wrong model choice

The word GPT has become a synonym for the category, which means the family gets chosen before anybody compares anything. It is a strong default and it is not the answer to every workload. Four situations where picking it by reflex costs you money or blocks the project outright.

• High-volume classification or extraction. Tagging tickets, pulling six fields off an invoice, routing an email. A small fast model does this at a fraction of the price and the outputs are frequently indistinguishable on your own test set. At a few hundred documents a day the difference between tiers is the difference between a rounding error and a line item somebody notices.
• A hard European residency requirement. When processing must stay in a named jurisdiction on terms your procurement team will accept, the shortlist is set by where a provider will run rather than by which model scores best. EU-domiciled providers and EU regions of the major clouds both answer this, and the answers differ in what they cost you.
• Reasoning across very large document sets. The families trade places on long-context work more often than marketing suggests, and this is the workload where the gap between them is still wide enough to matter. Test rather than assume.
• Anything that has to run on hardware you control. A proprietary model cannot be installed in your data centre, so the question stops being which is best and becomes which open family is good enough.

None of that is an argument against the default. It is an argument for a test that takes an afternoon: fifty of your own examples with known correct answers, run against three candidates, scored. The full comparison by dimension is in choosing an LLM for business, and the practical answer for most companies is more than one model behind an interface they own.

Three things to refuse

A company-wide rollout with no workflow attached. Buying seats for four hundred people and running a training session produces a fortnight of enthusiasm and a slow decline. Usage without a process attached is not adoption, and the numbers in the six-month review will say so.

A custom interface that duplicates the vendor’s own. If what you need is a chat window over general knowledge, the vendor already built a better one than a consultancy will. Pay for a build when it does something their product cannot: your documents, your permissions, your systems.

Anything sold as an AI strategy engagement before you have deployed anything. The first real workflow teaches you more about what your company needs than a roadmap does, costs less, and produces an artefact rather than a slide.