Where your CRM's AI has write access — and where it only has an opinion

AI in a CRM does not have one permission. It has five, and they fail in different directions. It can write fields, score leads and draft follow-ups without asking anyone; it cannot decide who owns a lead, cannot send the first message in your name, and cannot sign a forecast. The short version: automate what gets written and what gets calculated. What gets decided and what gets signed stays with a person.

That is not a take on the trend cycle. It is written, task by task, in the vendors' own documentation. HubSpot publishes exactly which fields it enriches on its own and the condition under which it stops. Salesforce publishes that the Einstein lead score is read-only, that it trains on your closed leads from the last three years, and that when you lack enough conversion history it falls back to a global model trained on anonymous data from other customers. Neither vendor promises the AI does your job. They promise something more useful: a different permission per task, and the permission is almost always narrower than the demo.

The five jobs behind the phrase "AI-powered CRM"

When a team says it automated its CRM with AI, it is describing five separate jobs that get bought together and configured separately.

Read the third column again: two rows say "writes" and three say "proposes", "drafts" or "computes". That is the line. The AI has write access to data it can reconstruct. Over decisions that move money or ownership of a book of business, it has a well-argued opinion. This is not a temporary limitation waiting on the next release; it is how the permissions are designed.

The setting that turns itself off quietly

HubSpot's enrichment documentation contains a sentence that belongs on the first slide of every implementation: automatic enrichment fills properties that are blank or empty, and does not overwrite values set by a user or another system. Manual enrichment can overwrite. Continuous enrichment keeps previously enriched fields current — but stops touching a property as soon as a user or another system edits it.

The practical consequence is uncomfortable. Your best rep, the one who corrects the job title and the headcount because she actually knows the account, is precisely the person who silently turns enrichment off for those fields. No alert fires. Nothing breaks. It surfaces months later as a segment report with a hole the size of your main book of business.

The fix is not asking the team to stop editing. It is splitting the fields: enrichment properties nobody touches by hand, and working properties a human does correct. That way the machine's value and the human's value never compete for the same cell. It is the same principle behind the data hygiene work we do — the field is rarely missing, two systems are just writing to it.

The score you cannot audit

In Salesforce, the Einstein lead score carries a lock icon: read-only. It trains on your closed leads from the past three years. Without enough conversion history it uses a global model trained on anonymous data from many customers. And the answer to "can I export the scores?" is no — they are available on the lead record, in list views and in reports, and nowhere else.

The September 9 support note adds the detail that breaks the data team's plan: the score is not a field on the Lead object at all. It lives in a separate object called ScoreIntelligence, exposed through the API but not built for the interface. Your pipeline report will not find it with a natural join.

Translated into the Monday meeting: the score is a prioritisation recommendation, not a fact about your business. You cannot recalculate it, you cannot join it to your warehouse without work, and you cannot explain why one lead moved from 74 to 81. If your sales process requires a rep to defend their priority in a pipeline review, this number is not evidence. It is queue order, which is worth a lot — and is a different thing.

The global-model fallback matters more than it sounds. A company with twelve months of history is not buying its own conversion pattern; it is buying the aggregated pattern of similar companies. That usually beats a hand-built points system. But when the committee asks "why is this lead first?", the honest answer is "because it resembles leads that converted at another company". Better to know that before the meeting.

Four permissions I would not hand over

Not out of distrust of the technology — because of what a mistake costs:

• Merging identity. A merge is irreversible and nobody notices the error until the account history is gone. Let the AI propose duplicates with a confidence score; let a person approve the merge.
• Changing owner. Assignment is a social agreement between reps, not a calculation. Automate it and every reassignment becomes a conflict nobody authorised.
• Touching price or discount. Any automation here is a commercial leak with good copywriting.
• Closing an opportunity. "Won" is an accounting statement. If a model writes it, the forecast stops being yours.

The order I would switch it on

For a company that already has a CRM and a team using it halfway:

1. Capture and enrichment. The only job where the AI truly writes and the error is reversible — a wrong field is fixed in a minute. Best return, lowest risk, start here.
2. Draft follow-ups, with mandatory review. For the first weeks a person approves every draft. The metric is not how many emails the model wrote; it is whether they get answered at the same rate as the hand-written ones.
3. Scoring last. It needs history, it produces a number nobody can audit, and it changes how the team behaves. Layering that on an undefined process is optimising a queue nobody respects.

The most common failure we see is not picking the wrong tool. It is buying the AI module because it came bundled in the plan, enabling it without deciding which job writes and which job only proposes, then discovering six months later that the team still qualifies by hand and the score only decorates the pipeline. An AI-enabled CRM without a permission policy is just a more expensive CRM.

Four numbers that tell you the permission is working

Vendor dashboards measure activity. These measure whether the access you granted does anything:

• Fields still blank at 30 days where enrichment was supposed to act. If that number is flat, the permission lives in the configuration, not in the operation.
• Share of leads with more than one owner in 24 hours. Tells you whether routing resolves, or whether the team is quietly correcting it by hand.
• Reply rate on drafts versus hand-written messages, same segment, same channel. The only honest test that automated writing is not costing you meetings.
• Gap between score decile and actual close rate, quarter over quarter. If the top decile does not close better than average, the queue is being ordered for the wrong reason.

If all four move the right way, the AI is working inside the permission you gave it. If only the first one moves, you bought a field cleaner with a nicer dashboard.

The opinion, plainly

AI in a CRM is for removing keystrokes, not judgement. The value is that the rep reaches the call with the field filled and the draft ready — not that a number tells them who to call first without being able to say why. The teams doing this well treat AI as a data and drafting layer, and leave assignment, price and forecast where they were: with a named person.

That split — which job writes, which job proposes, which job a human signs — is the first hour of any implementation worth the name. If you want to make those decisions before switching the module on, that is exactly what our CRM implementation work starts with. The rest of the map is already written here: the three-stage lead scoring framework, the automation flows that survive production and whether to consolidate or migrate your CRM. If you are still deciding what an AI CRM even means, start with the older overview and come back to this one for the permissions.

The useful question is not whether your CRM has AI. It is what you let it write.