For enterprise buyers, the capability question and the security question are inseparable. An AI that can take real actions is an AI that can cause real damage if the permission model is wrong. This section covers the four enterprise criteria that separate production-ready AI from demo-ready AI.
The weakest form of multi-tenancy is application-layer filtering: the API adds a WHERE org_id = ? clause to every query. This is fragile. A bug in any API route can expose cross-tenant data. The strongest form is database-level row-level security (RLS), where the database engine enforces tenant isolation before any application code runs. A bug in an API route cannot bypass RLS because the isolation is enforced at a layer below the application.
Ask vendors specifically: is multi-tenancy enforced at the application layer or the database layer? Application-layer enforcement is significantly weaker. For an AI that can execute write operations across your CRM, database-level RLS is not a preference — it is a requirement. Any AI action that could touch data belonging to another tenant without database-level enforcement is an unacceptable security risk.
The AI must respect the same permission model as a human user. If a sales rep cannot delete a contact, the AI acting on behalf of that rep must not be able to delete a contact. This sounds obvious but is frequently violated in bolt-on implementations, where the AI makes API calls using service-account credentials that bypass per-user permissions.
A production-ready RBAC model for an AI-native CRM needs granularity. A flat admin/rep distinction is insufficient. You need role definitions that can distinguish between who can view forecasts versus update them, who can access call recordings versus transcripts, who can send bulk sequences versus individual emails. The AI inherits these restrictions automatically — not by having separate AI-specific permission logic, but by being a first-class participant in the same permission model as every other actor in the system.
A seven-level RBAC hierarchy — owner, admin, manager, support, rep, member, external — covers the real permission surface of an enterprise sales team. Fewer levels typically means permission conflicts are resolved by giving more access than necessary, which is a security anti-pattern.
This is the criterion that most CRM vendors fail silently. If an AI took an action — updated a deal, sent an email, changed a contact — there must be an immutable, timestamped record of exactly what was requested, what the AI decided to do, what parameters it used, and what the outcome was. Not for debugging. For compliance.
Many platforms log AI "conversations" at the message level, which means you have a record of what a user asked but no record of what the AI actually did to your data. These are not the same thing. In regulated industries, and increasingly in standard enterprise due diligence, you need the latter.
The audit log must be immutable — append-only, with no mutation path available to the application. It must link the AI action to the user who initiated it, the tool definition that was invoked, the input parameters, the output, and the timestamp. Ask vendors: show me the audit record for the last ten AI actions in your demo environment. The presence of that record and its fidelity will tell you more about the architecture than any feature list.
AI systems make mistakes. The question is not whether mistakes will happen — it is what happens when they do. A production-ready AI execution layer must support rollback on reversible operations, and must clearly indicate when an operation is irreversible before executing it.
Reversibility requires that the system stores the pre-action state at write time, not as an afterthought. If the system was not designed for rollback, it cannot be added later without significant schema changes. This is an architectural decision, which means it either exists or it does not. Ask vendors specifically: if the AI bulk-updates 200 contact records incorrectly, what is the recovery path? If the answer is a manual export and re-import, rollback was not designed in.
The following questions are designed to be asked on a vendor call, ideally in a technical discovery session rather than a demo. Strong vendors will answer them specifically. Weak vendors will pivot to a feature list or ask to follow up. The pivots and deferrals are informative.
A native architecture has discrete, typed tool definitions — not a generic LLM instruction that the AI interprets freeform. If the vendor cannot show you a tool definition, the AI is not executing against a typed interface. This is the highest-signal question in the list.
Red flag: "The AI uses our API just like any integration would." That means no typed AI tool layer exists.You want to see the actual audit record — not a description of what it contains. It should include the user who initiated the action, the specific tool invoked, the typed input parameters, the output, and a timestamp. A conversation log is not an audit record.
Red flag: "We log all AI conversations." Ask specifically whether the log includes the write operations and their parameters.This question has a binary answer and vendors know it. Application-layer enforcement is weaker. Database-level RLS means the enforcement is in the database engine, below the application code. Any answer that is not "database-level RLS" is an answer you need to weight appropriately.
Red flag: The vendor does not know what RLS is, or needs to "confirm with the engineering team."There should be an explicit confirmation step for high-impact actions before execution, and a defined rollback path for reversible operations. Both should be architectural features, not manual processes. Ask to see the confirmation flow in the actual product.
Red flag: "You can always undo it in the UI." That is not rollback — that is a workaround.Cross-entity context is what separates AI that produces generic outputs from AI that produces contextually accurate outputs. An AI that cannot read call transcript sentiment when drafting a follow-up email is missing the most important context in the conversation. Ask them to demonstrate a cross-entity workflow, not describe one.
Red flag: "The AI can access all your CRM data." Ask for the specific list of entities and fields, not the summary claim.If the AI operates under service-level credentials, it can take actions that exceed the requesting user's permissions. This is a security design flaw. The AI must operate within the permission scope of the user who invoked it, not the permission scope of the system account that processes the request.
Red flag: Any explanation that involves the AI having a "system account" or "admin-level access" to execute actions.There is a practical downstream consequence of the architectural distinction that is worth making explicit for buyers evaluating total cost of ownership: bolt-on AI adds to your stack, while native AI consolidates it.
The reason is straightforward. A bolt-on AI lives on top of a CRM that was not designed for it. It cannot replace the specialist tools in your stack — call intelligence, proposal generation, sequence management, e-signatures — because it lacks the data model depth to match their capabilities. You end up with an AI assistant on top of a CRM, plus Gong, plus PandaDoc, plus Outreach. You have added a cost center without subtracting any.
A native architecture is designed from the start to be the execution layer across the functions it actually owns. The AI can orchestrate a deal workflow that touches sequences, call notes, proposals, and internal approvals because the data model connects those entities and the AI has typed tool definitions for each. Specialized legal signing can remain in the customer's selected provider without being misrepresented as a native capability.
When evaluating vendors on consolidation claims, apply the same data model test: ask which tools they claim to replace, and then ask the AI to do something that requires the capability of each tool. If the AI can execute a call coaching workflow, draft and route a proposal for approval, and manage a multi-step nurture sequence — all in a single session — those claims have substance. Require the vendor to identify any intentionally external workflow, such as contract signing, rather than implying complete replacement.
A typical 100-person sales team running HubSpot, Gong, Outreach, ZoomInfo, PandaDoc, and Calendly spends between $280,000 and $420,000 annually on software alone, before accounting for integration maintenance and the productivity cost of context-switching across six interfaces. A single platform that replaces all six at the schema level — not the marketing level — eliminates the integration surface entirely, not just the per-seat line items.
Use this checklist in vendor technical reviews. Every item should be verifiable in the product, not in a slide deck.
The evaluation framework in this guide is designed to be applied in a single technical session with any vendor. The six questions and the checklist should take less than ninety minutes to work through, and the answers will tell you more than any RFP or analyst report.
The broader point is that AI capability in enterprise software is no longer a function of which LLM a vendor uses. Every vendor has access to the same foundation models. Capability is now a function of architecture: how deeply the AI is integrated into the data model, how robustly the permission system governs AI actions, and how completely the audit trail captures what the AI did. These are engineering decisions made years before the current product, and they cannot be changed by a release note.
Ask the right questions, demand live demonstrations rather than slides, and treat any vendor who cannot answer the six questions above as having answered them — by not being able to.
Bring your vendor evaluation checklist to a PipeLance technical session. We will walk through every item in a live environment — no demo data, no prepared scripts.
Request a Technical Session