10 Questions to Ask Before Letting AI Touch Your CRM

Letting AI touch your CRM is the right move. Letting it touch your CRM blindly is not. The questions before letting AI touch your CRM aren’t really about whether the model is smart enough — today’s models can write Apex, build custom objects, and deploy changes just fine. The real questions are about what happens around the AI: whether every change is logged, whether you can undo it, and who is allowed to write. Get those wrong and a capable AI becomes a fast way to break things quietly. Get them right and you have a developer that never sleeps and never hides its work.

Here are the ten questions to ask any AI-plus-CRM setup — whether you’re evaluating a platform, a consultant’s script, or a weekend experiment of your own — before you hand over write access.

1. Where does the AI actually run — a laptop or a server?

If the answer is “on my laptop,” stop. An AI that develops against your production CRM from a personal machine means your write credentials live in someone’s local environment, the audit trail dies when the laptop sleeps, and nobody else can see what happened. Development against a live business system belongs on a dedicated, always-on server where access and history are controlled centrally. That’s the whole argument for running AI CRM development on a server, not a laptop — the runtime is part of the safety story, not an afterthought.

2. Is every change written to an audit log?

Ask to see the log. Not a promise of one — the actual record of who changed what, when, and through which key. If a change can happen without leaving a trace, you don’t have accountability, you have hope. A real AI code deployment safety layer treats the audit log as the primary artifact: every read, every write, every deploy is a line you can go back and read. When something looks off next month, the log is how you find out what the AI did in thirty seconds instead of thirty minutes of guessing.

3. Does it snapshot before it deploys?

The single most important safety mechanism isn’t a gate that stops the AI — it’s a snapshot taken before the change lands, so you can put things back the way they were. “Recoverable” beats “prevented” every time, because prevention slows down good work to guard against bad, while recovery lets the work move and keeps the undo button close. Ask specifically: is a snapshot captured before each deploy, and can you roll back to it in one step?

4. Can it test in a sandbox before production?

For Salesforce especially, there is no excuse for writing straight to production. A sandbox is a full replica of your production org where changes can be validated without touching live users or data. A serious setup deploys to a sandbox first, runs the required tests, and only then promotes to production. If an AI is pushing untested metadata directly into the org your business runs on, the model’s competence is irrelevant — the process is the problem.

5. Who holds the write access, and how many at once?

More write access is not better. The principle of least privilege — restricting access to the minimum needed to do the job — is decades-old security wisdom, and it applies perfectly to AI. The cleanest model is a single write key at a time per org: one AI session can change things, everyone else reads. Ask how many entities can write simultaneously. If the answer is “as many as have the password,” you’re one confused session away from two AIs fighting over the same object.

6. How does the AI connect — and can you revoke it in seconds?

The connection between your AI and your CRM should use scoped, key-based auth over HTTPS, not a shared login pasted into a prompt. The Model Context Protocol authorization spec is built on exactly this idea — OAuth-style access with tokens you can scope and revoke. The practical test: if you needed to cut the AI off from your CRM right now, could you? If revocation means changing a password everyone shares, that’s not access control, it’s a group chat.

7. Who owns the third-party accounts and keys?

When your AI sends email, calls an API, or provisions infrastructure, whose accounts is it using? The right answer is yours. A platform should be a hub that connects your AI to your CRM and your own third-party accounts — your email provider, your Google APIs — not a middleman that holds your keys hostage. If leaving the tool means losing access to accounts you depend on, you didn’t buy software, you rented a lock-in. Ownership is one of the first things worth checking in what an AI CRM developer actually is.

8. What happens when it makes a mistake — does it restrict or recover?

This is the philosophical fork, and it separates the serious tools from the nervous ones. Some setups try to prevent the AI from ever doing anything risky, which means they also prevent it from doing most of the useful things. The better answer is freedom plus visibility: let the AI move, log everything it does, snapshot before every deploy, and make recovery instant. No honest platform can promise an AI will never make a mistake — anyone claiming that is selling you a guarantee they can’t keep. What they can promise is that every mistake is visible and reversible.

9. Can more than one person’s AI work without colliding?

If your team grows past one person typing into one AI, the collision question becomes real. Two sessions writing to the same org at the same time is how you get half-deployed changes and mysterious overwrites. The one-write-key model for multi-user AI development solves it by passing a single write baton: many people can read and draft, but only one holds write at a time. Ask how the setup handles two teammates working the same afternoon — if the answer is a shrug, plan for chaos.

10. How fast can you get started — and what does it cost?

Speed of setup tells you how much is automated versus how much is a person doing manual work behind a curtain. The best answer is zero-touch: buy, and the server, static IP, DNS, and SSL are provisioned automatically with no tickets and no waiting. On cost, demand a straight answer. Sentinel’s is public: $500 per month per Sentinel, plus a one-time $2,500 onboarding fee on your first Sentinel only. No per-seat surprises, no metered mystery. If a vendor won’t tell you the price on the page, that’s its own answer.

The pattern behind all ten

Read the questions again and you’ll notice none of them ask “is the AI good enough?” They ask whether the system around the AI makes its work visible and recoverable. That’s the actual definition of safe AI development: not an AI that never touches anything dangerous, but a setup where every touch is logged, every deploy is snapshotted, and every change can be undone. Restriction is the wrong safety model. Visibility and reversibility are the right ones — and they’re exactly what a real platform is built to give you.

Sentinel is that platform: your AI becomes your CRM developer, with every change logged and every deploy recoverable. Start your Sentinel and put your AI to work.