Adding AI to an enterprise platform is an integration problem with a model attached. The platform's permissions, data gravity, limits, and audit requirements aren't friction to route around — they're the spec. Run the AI inside the permission model, go async to respect limits, and make every AI change attributable and reversible.
Most AI writing assumes a blank slate: a fresh app, a clean database, a model, and a chat box. That’s not where most of the world’s important software lives. It lives on enterprise platforms — CRMs, ERPs, systems of record — that have been accreting business logic, permissions, and data for a decade.
Putting AI in front of that is a genuinely different engineering problem. After years building on enterprise platforms, here’s what I’ve learned the demos never prepare you for.
The data has gravity, and rules
On a greenfield app, data is something you fetch. On an enterprise platform, data is the entire point — and it comes wrapped in rules that predate your feature by years.
A record isn’t just fields. It has an ownership model, a sharing hierarchy, field-level security, validation rules, and triggers that fire when it changes. Your AI feature doesn’t get to ignore any of that. The moment an LLM reads or writes platform data, it inherits every constraint the platform enforces — and if you bypass them for convenience, you’ve created a security hole with the platform’s most sensitive data behind it.
The rule: the AI layer must run inside the platform’s permission model, not around it. If a user can’t see a record, the model answering their question must not see it either. Retrieval has to be permission-aware from the first line of code, not bolted on later.
Context is expensive to assemble and easy to leak
LLMs need context. On a platform, the relevant context for any question is scattered across related objects — an account, its contacts, its open cases, its history — joined by relationships the platform understands and your retrieval layer has to reconstruct.
Two failure modes show up immediately:
- Too little context and the model answers generically, ignoring the specific record the user is looking at. It feels bolted-on because it is.
- Too much context and you’ve stuffed the window with related records the user may not even have permission to see — a data leak dressed up as a helpful summary.
Assembling the right context — permission-filtered, relevant, compact — is most of the actual work. The prompt is the last 5%.
Platforms have limits, and they bite under load
Enterprise platforms are multi-tenant. They protect themselves with limits — on query volume, on processing time, on API calls, on how much you can do in a single transaction. Your AI feature, which wants to fan out across related records and make external model calls, runs straight into them.
The naive design — synchronously gather context, call the model, write the result, all in one transaction — will blow a limit the first time it meets a large account. The architecture that survives is asynchronous and decoupled: do the AI work off the critical path, respect the platform’s processing model (queues, platform events, async jobs), and never make a user’s save wait on a model call that might take twelve seconds.
Wrong answers have an audit trail
In a consumer app, a bad AI suggestion is a shrug. On a system of record, every change is consequential — it’s what the business runs on, and often what auditors and regulators inspect later. “The AI did it” is not an acceptable line in a compliance review.
This raises the bar on a few things that are optional elsewhere:
- Attribution. When AI writes to a record, that has to be visible and traceable. Who — or what — made this change, with what input?
- Reversibility. A confidently wrong update to a system of record needs to be as easy to undo as it was to make.
- Human checkpoints on consequential actions. Drafting a field value for review is fine. Silently mutating financial or customer data is not.
The reframe
Building AI on an enterprise platform isn’t “add an LLM.” It’s an integration problem with a model attached — and the platform’s existing rules (permissions, limits, governance, audit) aren’t obstacles to route around. They’re the requirements. The teams that get this right treat the platform’s constraints as the spec, not the friction.
The model is the easy part. Respecting the system it’s sitting on top of is the job.
