Selected work
Replacing an AI platform without reopening the access model
A publicly traded cloud software company moved off Google Gemini and Vertex to Claude Enterprise, 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 Google Gemini and Vertex, and then decided to standardize on Claude Enterprise 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 Claude Enterprise 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.
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.
- Support live at go-live
Day 1
Support live at go-live
Staffed from the first morning, so access questions were answered rather than worked around.
- Identity control plane
One
Identity control plane
The AI platform joined the existing directory and joiner-mover-leaver process instead of standing up its own.
- Model platforms consolidated
Two → one
Model platforms consolidated
Gemini and Vertex gave way to a single standardized platform, governed under one access model.
Lessons
What this means for mid-market leaders
A mid-market 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
The order is the whole thing. Integrating a new AI platform into the identity processes you already run is a week of work before go-live and a quarter of untangling afterwards. If you take one thing from this page, take the ordering.
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 look like an access console. Review each one the way you would review a new integration's service permissions — scope it, attribute it to the requesting user, and log it.
A platform switch is a governance opportunity
The controls you never wrote for the outgoing platform are easiest to write while the incoming one is being configured. Nobody has habits yet, no one is defending an exception, and the work is already open. Waiting until things settle means writing policy against installed 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: put the hours you have 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.
Most of this method is portable. The identity work is the same work whether the organization has 900 users or many times that; what changes is how much of it one person can carry.