Selected work
Replacing an AI platform without reopening the access model
A publicly traded cloud software company replaced one enterprise AI platform with another, quickly, and came out the other side with one identity-governed AI estate spanning cloud and on-premises systems.
Challenge
A platform decision made at speed
The company had standardized on one vendor's AI platform and its model services, then decided to standardize on a different vendor instead. The decision was made at speed and the platform switch was expected to follow at the same speed — which is where this kind of migration usually goes wrong.
A model platform is not a self-contained purchase. It sits on top of the directory, the joiner-mover-leaver process, the data classification scheme and whatever access policy already governs the systems it will be asked to read from. Swapping the platform out means every one of those attachment points is briefly loose. The tempting shortcut — stand the new platform up beside the old controls, integrate identity properly later — produces a second, unreviewed access model that nobody owns.
Two further constraints shaped the work. The estate was genuinely hybrid: workloads that had to stay on hardware the company controlled sat alongside workloads that belonged in a vendor's cloud, and the boundary between them had never been written down in one place. And consumption-priced AI had no cost owner — nothing measured token use, so finance had no way to forecast a bill that would grow with every team that adopted the tool.
Approach
Identity first, governance in parallel
The engagement ran identity first and governance in parallel with rollout, on the principle that controls wired in before go-live cost less than controls retrofitted after.
Step 01
Integrated the new platform into the existing identity processes
No parallel directory, no platform-local user list. Provisioning, group membership and deprovisioning were attached to the joiner-mover-leaver process the company already ran, so an access decision made in the directory took effect in the AI platform, and a leaver lost the AI platform at the same moment they lost everything else. This was the first workstream, not the last, because every later decision inherits from it.
Step 02
Configured MCP connectors under the access model, not beside it
Connectors are where an AI platform stops being a chat window and starts reaching into systems of record. Each connector was scoped deliberately — which system, which data, on whose authority — and configured so requests carry the identity of the person behind them rather than a shared service account. That distinction is what keeps the audit trail intelligible once agents are acting on a user's behalf.
Step 03
Clarified the hybridized AI architecture
The cloud and on-premises halves of the estate were documented as one architecture: data paths, model hosting, network boundaries, and the single identity layer governing both. The point was to make the placement question answerable in advance for the next workload, rather than re-argued each time a team proposed one.
Step 04
Staffed Day 1 support at go-live
Support was in place the morning the platform went live, not stood up after the first week of tickets. Early questions in a migration are disproportionately about access and permissions — exactly the questions that turn into workarounds if they go unanswered, and workarounds are how a clean access model degrades.
Step 05
Built the citizen-developer network and a center of excellence
Charters, documentation, training and an operating cadence, plus a named network of practitioners inside the business units. The governing idea: an internal group with the authority to say yes under known conditions, so that building with AI has a supported path rather than a shadow one. The center of excellence owns the conditions; the citizen developers work inside them.
Step 06
Implemented token measurement and cost controls for FinOps
Consumption pricing needs an owner and an instrument. Token use was measured and attributed, and cost control tooling handed to FinOps, so growth in spend could be traced to the team and the use case driving it — and so a forecast could be defended rather than guessed at.
Architecture
What it resolved to
The same three tiers this practice designs toward everywhere else. What the engagement changed was the model layer — two vendor platforms became one, alongside the workloads that stayed on hardware the company controlled. The tier above it did not move.
What changed
One estate, one access model
The company ended the engagement with a fully hybridized AI estate under one identity model: cloud and on-premises workloads governed by the same access policy, with the AI platform inside that policy rather than adjacent to it.
Access to AI capability now follows from a directory decision. Adding someone, moving them between teams and removing them are the same operations they were before, and the AI platform is subject to them. Connector reach is scoped per system and attributable per person.
Governance outlived the rollout. The center of excellence holds the charters, documentation and training; the citizen-developer network gives teams a supported way to build; FinOps holds a measured, attributable view of consumption. None of that depended on the consultant staying.
Day 1
Support live at go-live
Staffed from the first morning, so access questions were answered rather than worked around.
One
Identity control plane
The AI platform joined the existing directory and joiner-mover-leaver process instead of standing up its own.
Two → one
Model platforms consolidated
Two overlapping vendor platforms gave way to a single standardized one, governed under one access model.
Lessons
What this means at a smaller scale
A smaller organization will not run this engagement at this size. It will face the same five decisions, with a smaller team and less room for a wrong turn.
Sequence identity before the platform, not after it
Sequence determines cost. Integrating a new AI platform into the identity processes already in place is roughly a week of work before go-live, and a quarter of remediation afterwards. Of everything on this page, the ordering is the transferable part.
Treat connectors as access grants, because that is what they are
A connector to a document store or a ticketing system is a decision about who can read what, made in a tool that does not present as an access console. Each should be reviewed as a new integration's service permissions would be: scoped, attributed to the requesting user, and logged.
A platform switch is a governance opportunity
Controls never written for the outgoing platform are most easily written while the incoming one is being configured. No usage habits have formed, no exceptions are being defended, and the work is already open. Deferring until the platform settles means writing policy against established behavior instead.
Fund the first day, not the first month
Support concentrated at go-live prevents the workarounds that support spread thinly across a month has to unwind. With a small internal team this is a scheduling decision more than a budget one: the available hours are best placed on the day they compound.
Meter consumption from the start, or don't buy consumption pricing
Token spend that cannot be attributed to a team and a use case is a number finance can only react to. Measurement is inexpensive to add at rollout and awkward to retrofit once usage is broad — and without it, the first surprising invoice becomes an argument about the tool rather than about the workload.