August 2, 2026. That is the date when the EU AI Act's requirements for high-risk AI systems take full effect. If your company sells into Europe, has European employees, or processes data from EU-based contacts, your sales AI is in scope. Most sales leaders have not thought about this yet. They should.
The penalties are substantial: up to 35 million euros or 7% of global annual revenue, whichever is higher. For context, GDPR fines cap at 4% of revenue. The EU AI Act goes further. And unlike GDPR, which primarily targeted data controllers and processors, the AI Act places obligations directly on AI system providers, deployers, and importers. If you buy a CRM with AI features and deploy it in the EU, you are a deployer. You have obligations.
This is not a theoretical concern for 2028. The compliance clock is running now, and procurement teams that ignore it will face a scramble in Q3 that makes SOC 2 audits look relaxed.
What the EU AI Act Requires
The Act categorizes AI systems into four risk tiers: unacceptable (banned), high-risk, limited risk, and minimal risk. Most sales AI falls into the limited risk or high-risk categories depending on what the AI does and how much autonomy it has.
AI that scores leads, prioritizes accounts, or recommends pricing falls into limited risk territory. AI that makes automated decisions affecting employment (performance scoring, commission calculations, territory assignments) may qualify as high-risk under Annex III, Category 4, which covers AI systems used in employment and worker management.
If your AI system calculates commissions, adjusts quotas, or scores rep performance, the EU AI Act may classify it as high-risk under the employment category. High-risk classification triggers the full set of obligations: risk management systems, data governance, technical documentation, transparency, human oversight, accuracy, robustness, and cybersecurity. Most CRM vendors have not acknowledged this classification risk publicly.
The Five Obligations That Matter for Sales Tech
Strip away the legal language and there are five requirements that will hit sales technology buyers directly.
1. Transparency: Tell People When AI Is Involved
Article 50 requires that people interacting with an AI system be informed that they are doing so, unless this is obvious from the circumstances. For sales teams, this means: if your AI assistant sends an email on behalf of a rep, the recipient may need to know it was AI-generated. If your chatbot handles inbound leads, visitors must be told they are talking to AI, not a person.
Most sales engagement platforms do not flag AI-generated content in outbound emails. Most live chat implementations do not distinguish between AI and human responses until a handoff happens. Both are potential compliance gaps.
2. Documentation: Prove How Your AI Works
High-risk AI systems require technical documentation that describes the system's intended purpose, design specifications, training data, performance metrics, and known limitations. For deployers (that is you, the company using the AI), you need to maintain logs of AI system outputs and be able to produce them on request.
This is where most sales AI vendors fall short. Ask your CRM vendor for their technical documentation package. If they cannot produce one, they are not ready for August 2026. If they can, check whether it covers your specific use cases or just their general platform capabilities.
Article 26 requires deployers of high-risk AI to keep logs automatically generated by the AI system for a period appropriate to the intended purpose, and at least six months. If your CRM's AI features do not produce an audit trail of every AI-initiated action, every recommendation, and every automated decision, you cannot comply. A platform without comprehensive audit logging is a compliance liability after August 2, 2026.
3. Human Oversight: Someone Must Be in the Loop
High-risk AI systems must be designed so that they can be effectively overseen by a human during the period of use. This means an AI system that autonomously sends emails, updates deal stages, or modifies pipeline data needs a mechanism for human review before or after execution.
The question for your current vendor: does your AI have authority modes? Can you configure it so that high-impact actions require human approval while low-risk actions execute automatically? Or is it all-or-nothing: either fully autonomous or fully manual?
A binary approach fails the human oversight test. The regulation expects proportional oversight. Low-risk actions (logging a note, updating a field) can be automated. High-risk actions (sending an email to 500 contacts, deleting records, adjusting commission calculations) should require confirmation. Your platform needs to distinguish between these tiers.
4. Data Governance: Know What Trained Your AI
Article 10 requires that training, validation, and testing data sets be subject to appropriate data governance practices. For sales AI, this raises questions about enrichment data sources, intent signal providers, and any AI model fine-tuned on your CRM data.
If your vendor's AI was trained on data scraped from the web without consent, or if enrichment providers cannot demonstrate legal basis for the data they supply, you inherit that risk as a deployer. Ask your enrichment vendor for their Article 10 compliance statement. If they look confused, find a new enrichment vendor before August.
The AI Act requires that AI systems maintain data integrity and prevent unauthorized access. If your CRM vendor runs a shared-tenant architecture where one customer's data could theoretically leak into another customer's AI model or search results, that is a compliance problem. Database-enforced multi-tenancy using Row Level Security (Postgres RLS) is the standard that auditors will expect. Application-level filtering is not sufficient.
5. Risk Management: Assess and Mitigate Continuously
High-risk AI deployers must establish a risk management system that identifies and analyzes known and foreseeable risks, estimates and evaluates risks that may emerge, and adopts appropriate risk management measures. This is not a one-time assessment. It is ongoing.
For sales AI specifically, the foreseeable risks include: biased lead scoring that disadvantages certain demographics or geographies, AI-generated content that makes false claims about products or competitors, automated outreach that violates contact preferences, and commission calculations that produce incorrect results without human review.
Your vendor should be able to explain their risk management framework for each of these scenarios. If they cannot, you will need to build your own, which adds cost and complexity to a platform that was supposed to reduce both.
The Vendor Evaluation Checklist
When you sit down with your CRM or sales AI vendor before August 2026, ask these ten questions. Grade each answer on a 1-to-3 scale: 1 means they do not have this, 2 means partial coverage, 3 means full compliance readiness.
- Can you produce technical documentation for your AI system as required by Article 11?
- Does your platform maintain automatic logs of all AI-initiated actions with timestamps, user context, and outputs?
- Can I configure different authority levels for AI actions based on risk level (e.g., auto-execute low risk, require approval for high risk)?
- Does your AI disclose to external parties (email recipients, chat visitors) when they are interacting with AI-generated content?
- What is your data governance framework for training and enrichment data? Can you produce an Article 10 compliance statement?
- Is your multi-tenancy enforced at the database level (RLS) or at the application level?
- Can I export a complete audit trail for a specific time period showing all AI actions taken on my data?
- Do you have a documented risk management system for your AI features?
- What is your process for bias testing in lead scoring, deal intelligence, and any AI-driven prioritization?
- If I need to disable specific AI features to comply with a regulator's request, can I do that granularly without losing non-AI functionality?
A vendor scoring below 20 out of 30 is not compliance-ready. A vendor scoring below 15 is a risk you should not carry into August.
If your company is headquartered in the U.S. but has a single customer, prospect, or employee in the EU, the AI Act applies to you. The extraterritorial scope mirrors GDPR. U.S. companies that assumed GDPR would not affect them learned that lesson the expensive way. Do not repeat it with the AI Act. And if you are also navigating state-level privacy laws across 20 U.S. states, the compliance burden compounds fast.
Where Revian Stands on Compliance Readiness
We built Revian with audit-first architecture because we believed regulators would eventually require it. That bet is paying off.
Every AI action in Revian produces a complete audit record: who initiated it, what the AI did, what data it accessed, what it changed, and when. There are 279 mutation paths in the system, and every one is logged. This is not a feature we added in response to the AI Act. It is the foundation the platform was built on.
Authority modes let organizations configure AI execution at a granular level. Low-risk actions (updating a contact field, logging a call note) can auto-execute. Medium-risk actions (sending an email, creating a sequence) can require one-click confirmation. High-risk actions (bulk operations, data deletion, commission adjustments) can require manager approval. This maps directly to the proportional human oversight that Article 14 requires.
Database-enforced multi-tenancy through Postgres Row Level Security means one organization's data cannot leak into another's AI context. This is not application-level filtering that can be bypassed with a code bug. It is database-level enforcement that applies regardless of how data is accessed. The cost of shadow AI breaches makes this architecture choice a business decision, not just a technical one.
Provider-agnostic AI means Revian does not depend on a single model provider. If a specific AI model faces regulatory challenges in the EU, the system can switch providers without disrupting operations. All 119 AI tools use Zod-validated schemas, which means every input and output is typed and auditable. No freeform, unstructured AI interactions that cannot be documented.
The enterprise identity infrastructure including SSO, SCIM provisioning, and 7-level RBAC supports the access control requirements that auditors will expect. Permission-scoped AI execution means the AI can only do what the user is authorized to do. It cannot escalate privileges or access data outside the user's permission scope.
What to Do Between Now and August
Five steps, in order.
Step 1: Classify your AI use cases. Map every AI feature you use in your sales stack against the EU AI Act risk categories. Lead scoring, deal intelligence, content generation, commission calculation, performance scoring. Determine which are limited risk and which may qualify as high-risk.
Step 2: Audit your current vendor's logging. Can you export a complete record of every AI action taken in your CRM over the past 30 days? If the answer is no, that vendor cannot support Article 26 compliance.
Step 3: Request compliance documentation from every AI vendor. Send the 10-question checklist above. Set a 30-day response deadline. Vendors that cannot respond in 30 days will not be ready in five months.
Step 4: Assess your multi-tenancy architecture. If you are on a shared-tenant platform with application-level data separation, understand the risk. If a breach occurs after August 2, the regulatory response will be more severe than it would be today.
Step 5: Build your risk management framework. Even if your vendor handles most of the technical requirements, you as the deployer need a documented risk management system. Identify risks, assess likelihood and severity, document mitigation measures, and schedule periodic reviews.
August 2 is 145 days away. The teams that start now will be ready. The teams that wait until June will not.
Compliance starts with architecture.
Revian's audit trail, authority modes, and database-enforced multi-tenancy were built for exactly this regulatory moment. See how they work.
Request Access