Salesforce Einstein Under the EU AI Act: Classify by Use
Salesforce Einstein risk tier depends on use, not product. Learn when Einstein is minimal, limited, or high risk and what deployers owe by Dec 2027.
Most Salesforce Einstein deployments land at minimal risk. That is the correct starting point — and the one the original v1 framing missed by leading with the high-risk scenario list. The EU AI Act (Regulation (EU) 2024/1689) does not categorise Einstein as a product. It categorises what you do with it. Get that distinction right before opening a compliance workstream.
Einstein covers a family of features: lead and opportunity scoring, sales forecasting, service case routing, next-best-action recommendations, Einstein Copilot (a generative chat layer), and Einstein GPT features that produce written content or summaries. Each can land in a different risk tier depending on the deployment context. This article walks through the classification logic, identifies the narrow scenarios where Einstein climbs toward high risk, and explains what your organisation needs to do as a deployer.
What risk tier does Einstein actually fall into?
For the vast majority of CRM deployments — B2B lead scoring, pipeline forecasting, service case triage, marketing campaign analysis — Einstein is minimal risk. The EU AI Act attaches no mandatory obligations to minimal-risk AI. You may choose to follow voluntary codes of practice, but you are not legally required to do so.
Limited risk applies under Article 50 where Einstein generates content that a user might mistake for human-produced, or where a chatbot interacts with natural persons without identifying itself as AI. Einstein Copilot and Einstein GPT features that handle customer-facing chat or produce written outputs fall here from 2 August 2026. The obligation is narrow: disclose the AI nature to the person interacting with it. It does not require a risk management system or technical documentation.
High risk requires a specific configured use that falls within Annex III of the Act. Einstein does not reach this tier by default. It reaches it only when it is configured for one of the Annex III purposes described below.
When Einstein becomes high risk: three scenarios
Scenario 1 — Recruiting and HR decisions (Annex III, point 4)
Annex III point 4 covers AI used in employment, workers management, and access to self-employment. Point 4(a) specifically targets systems used for recruitment or selection of natural persons — including screening CVs, scoring applicants, or shortlisting candidates for interview. Point 4(b) covers decisions on promotion or termination.
If you configure Einstein Prediction Builder to rank job applicants, score candidates against historical hiring data, or flag employees for performance reviews that could lead to termination, you are operating a high-risk system under Annex III point 4.
The key distinction: B2B lead scoring and account prioritisation — Einstein scoring companies rather than individual natural persons in a hiring context — does not fall here. Annex III point 4 is about decisions that affect workers and jobseekers as natural persons.
Scenario 2 — Creditworthiness of natural persons (Annex III, point 5(b))
Annex III point 5(b) covers AI systems used to assess the creditworthiness of natural persons or establish their credit scores. This applies when Einstein Scoring is used by a lender, insurer, or fintech to determine whether a natural person (a consumer, a sole trader) qualifies for credit or a financial product.
The critical distinction the original article conflated: a B2B fintech using Einstein to assess merchant creditworthiness — scoring a company's invoice-financing eligibility, evaluating a business's payment history — is generally not scoring a natural person's creditworthiness under Annex III 5(b). It may be scoring an SME or a corporate entity. That is not the same thing. Annex III 5(b) refers to natural persons, not legal entities.
Where a sole trader or self-employed individual is assessed — where the business and the person are not legally separated — the analysis becomes more fact-specific and you should treat it as potentially in scope. Take legal advice on the specific configuration.
The fraud-detection carve-out also matters: AI used solely to detect financial fraud does not fall under Annex III 5(b), even if it processes creditworthiness signals as inputs.
Scenario 3 — Other Annex III configurations (points 1, 2, 3, 6, 7, 8)
Einstein deployed in a law enforcement CRM context, where case-routing or predictive features influence decisions about individuals' risk of offending, would engage Annex III point 6. Einstein deployed by a public authority for migration or border-control case management could engage point 7. These are edge cases for typical commercial Einstein users. If your sector is law enforcement, migration services, or court administration, review the full Annex III list against your specific Einstein configuration.
The Article 6(3) filter: not every Annex III configuration is high risk
Even when Einstein touches an Annex III area, Article 6(3) provides a filter. A system is not high risk if it does not pose a significant risk of harm to health, safety, or fundamental rights. The filter applies if the system performs a narrow procedural task, supports a previously completed human decision rather than replacing it, detects patterns for informational purposes without influencing individual determinations, or does preparatory work only.
The catch: any system that profiles natural persons — building individual profiles to draw inferences about them — is always high risk regardless of the 6(3) filter. Einstein's capability to build individual customer or employee profiles matters here. If Einstein is profiling individuals in an Annex III context, do not assume 6(3) saves you.
Providers (Salesforce) and deployers who claim the Article 6(3) exemption must document that assessment. Under Article 49, the system still needs to be registered in the EU database even if it claims the exemption.
Your role: you are almost certainly a deployer
Salesforce develops and places Einstein on the market under its own name. That makes Salesforce the provider under Article 16. Your organisation — purchasing Einstein licences and running them in your environment — is the deployer under Article 26.
The provider/deployer split matters because the heaviest obligations fall on the provider. Salesforce must establish the Article 9 risk management system, compile the Article 11 / Annex IV technical documentation, run the Article 43 conformity assessment for high-risk features, and provide deployers with instructions for use. You should be asking Salesforce for this documentation before deploying Einstein in any high-risk configuration.
One role-shift scenario is worth flagging. Under Article 25, a deployer becomes a provider if it substantially modifies the system or changes its intended purpose. If your technical team builds a custom Einstein Prediction Builder model using Salesforce's infrastructure but trained on your proprietary data and deployed for purposes Salesforce did not intend — screening job applicants when Salesforce's documentation scopes the product for lead scoring — you may have shifted into provider obligations. Document the intended use precisely.
Deployer obligations for high-risk Einstein configurations
If your Einstein deployment is genuinely high risk, Article 26 sets out what you owe:
Use within the intended purpose. You must operate Einstein within the use parameters Salesforce has documented. Repurposing a sales-scoring model for recruitment screening — even internally — constitutes a change of intended purpose and can trigger Article 25 role-shift.
Human oversight (Article 14). Decisions that materially affect individuals — job-application rejections, credit denials — require meaningful human review. That means reviewers who understand Einstein's outputs, know its limitations, and have documented authority to override. Token sign-off does not satisfy Article 14.
Monitoring and logging (Article 26). Keep logs of the system's operation for at least six months. Monitor for performance degradation, bias drift, or outputs that diverge from expected behaviour.
AI literacy (Article 4). In force since 2 February 2025. Your staff who use, oversee, or rely on Einstein outputs must have a level of AI literacy appropriate to their role. This is not a training checkbox — it means understanding what the model does, where it can fail, and how to apply human judgment.
Fundamental Rights Impact Assessment (Article 27). A FRIA is required before deployment where you are a public body, or where you are deploying an Annex III 5(b) creditworthiness or 5(c) life/health-insurance system. Most private-sector Einstein deployers — sales teams, marketing operations, service desks — do not owe a FRIA.
Incident reporting. Under Article 26, you must notify Salesforce (and, where required, the national competent authority) of serious incidents — systematic bias affecting a protected group, outputs causing material harm, data security failures affecting Einstein's training data. Article 73's strict timelines (15 days generally; 2 days for widespread or critical-infrastructure incidents; 10 days if a death results) apply to the provider's duty to notify authorities, but your duty to flag to the provider is immediate.
Einstein Copilot and generative features: Article 50 from August 2026
Einstein GPT and Einstein Copilot features that interact with customers or produce written outputs — summaries, email drafts, case notes — are not high risk by virtue of being generative. They are limited risk under Article 50.
From 2 August 2026, Article 50 requires:
- Chatbots and AI agents interacting with natural persons must disclose the AI nature of the interaction, unless this is obvious from context.
- AI-generated content — text, images, audio — that could be mistaken for human-produced must be labelled.
Article 50 applies regardless of the underlying model's complexity. Einstein Copilot producing a customer email carries a disclosure obligation. That obligation does not require a risk management system, technical documentation, or conformity assessment.
Note the tense: Article 50 applies from 2 August 2026 — it is a near-future obligation as of mid-2026, not yet in force.
GDPR interaction: Article 22 and automated profiling
Any Einstein deployment that involves profiling of natural persons and produces decisions that significantly affect them runs into GDPR Article 22, which restricts solely automated decision-making. This is a separate legal framework from the EU AI Act and sits alongside it. Einstein's lead scoring, contact enrichment, and individual customer-health scoring features can engage GDPR Article 22 where the output is treated as the decision rather than an input to a human decision.
The two regimes are distinct. EU AI Act compliance does not subsume GDPR compliance, and vice versa. Where Einstein processes personal data, map both frameworks before deployment.
The deadlines (corrected)
The source article stated deadlines of 2 August 2026 and 2 August 2027 for high-risk obligations. Both are wrong.
Under the Digital Omnibus, agreed in May 2026 (political agreement; formal adoption expected before 2 August 2026):
- 2 December 2027 — stand-alone high-risk AI systems under Annex III (the date that covers Einstein in HR or credit configurations).
- 2 August 2028 — high-risk AI embedded as safety components in Annex I regulated products. Einstein is not an Annex I product.
- 2 August 2026 — Article 50 limited-risk transparency and general application of the Act. Article 5 prohibitions and Article 4 AI literacy have applied since 2 February 2025.
December 2027 is not far. Technical documentation under Article 11 / Annex IV, a risk management system under Article 9, and a conformity assessment under Article 43 for a genuinely high-risk Einstein deployment take months to assemble correctly. The deferral is breathing room, not a reprieve.
How Confir helps
The first two steps for any Einstein deployer are the same: register the deployment and classify it. Confir's intake process walks you through the use-case questions that determine which Annex III category — if any — applies to your Einstein configuration. Same intake, same result: the classification logic is deterministic and rule-based, so you get a defensible, explainable finding rather than a consultancy opinion.
Once classified, Confir derives your role (deployer under Article 26, or provider if Article 25 has shifted you) and generates the compliance workplan for what your specific tier actually requires. For minimal-risk Einstein deployments, that workplan is short. For a genuinely high-risk HR or credit configuration, it maps the full Article 9 / 11 / 14 / 43 stack.
Frequently Asked Questions
Is Salesforce Einstein high risk under the EU AI Act?
Not by default. Einstein's risk tier depends entirely on how you configure and use it. Standard CRM functions — pipeline forecasting, lead scoring of companies, service case routing, marketing analytics — are minimal risk with no mandatory obligations. Einstein becomes high risk only when configured for an Annex III purpose: recruiting and HR decisions (Annex III point 4), creditworthiness assessment of natural persons (Annex III point 5(b)), or other listed use cases. Start with the use case, not the product name.
B2B lead scoring looks like credit scoring — does it trigger Annex III 5(b)?
No, in most cases. Annex III point 5(b) targets creditworthiness assessment of natural persons. B2B lead scoring typically evaluates companies — legal entities, not natural persons. Scoring whether an enterprise prospect is likely to convert, or whether a corporate customer is a good credit risk for invoice financing, does not fit 5(b). The line blurs when the "business" is a sole trader or self-employed individual whose personal finances are inseparable from the business assessment. In those configurations, take a conservative view and verify the specific deployment against the Annex III text.
What does Article 50 require for Einstein Copilot?
Einstein Copilot and other generative Einstein features interacting with natural persons must disclose the AI nature of the interaction from 2 August 2026, unless it is obvious from context. AI-generated text produced by Einstein features — email drafts, case summaries, customer-facing responses — must be labelled as AI-generated where a person might mistake it for human output. This is a transparency duty under Article 50, not a high-risk obligation. It does not require a risk management system or conformity assessment.
What penalties apply if we get the classification wrong?
Non-compliance with high-risk AI obligations (Articles 9–15, 26) carries fines up to €15,000,000 or 3% of total worldwide annual turnover, whichever is higher (Article 99(4)). Non-compliance with Article 50 transparency duties falls under the same €15M/3% ceiling. For smaller companies, Article 99(6) caps fines at the lower of the percentage or the fixed amount — a proportionality protection worth noting, but not a reason to skip classification work. The fine for supplying incorrect information to authorities is up to €7,500,000 or 1% of turnover (Article 99(5)).
Who is the provider — Salesforce or us?
Salesforce is the provider under Article 16 for the Einstein features it develops and places on the market. Your organisation is the deployer under Article 26. That means Salesforce bears the primary burden for technical documentation, risk management systems, and conformity assessments — and must provide you with instructions for use covering how to deploy Einstein within the intended purpose. If your team substantially modifies Einstein or deploys it for a purpose Salesforce did not intend, Article 25 may convert your organisation into a provider with the full high-risk obligation stack.
Do we need a Fundamental Rights Impact Assessment (FRIA)?
A FRIA under Article 27 is required before deploying a high-risk AI system if you are a public-sector body, or if you deploy an Annex III 5(b) creditworthiness or 5(c) life/health-insurance system. Most private companies using Einstein for sales, marketing, and service operations do not owe a FRIA. A private employer deploying Einstein for recruitment screening (Annex III point 4) does not automatically owe one either — point 4 deployers are not in Article 27's explicit scope the way public bodies and 5(b)/5(c) deployers are.
What does "AI literacy" under Article 4 require for Einstein users?
Article 4 has applied since 2 February 2025. It requires that anyone in your organisation who uses, oversees, or relies on Einstein outputs — sales reps acting on lead scores, managers reviewing Einstein-generated forecasts, HR staff using Einstein recommendations — has a level of AI literacy appropriate to their role. That means understanding what Einstein does, what its outputs represent, where it can fail, and how to apply judgment rather than treating the score as determinative. Document the training, even if it is lightweight, because Article 4 is already in force.
Related guides
- enterprise compliance guide
- 2026 implementation roadmap
- Article 9 risk management system
- Articles 6–29 compliance checklist
- Article 6 classification decision tree
- Article 3 key definitions
- EU AI Act fundamentals
- SaaS compliance framework
Manage your EU AI Act compliance in one place
Confir automates risk classification, technical documentation, and audit trails for any company. No consultants. No 6-month projects. 7-day free trial.
Start free trial →