Business

When Your AI Touches SAP, Salesforce, and the Knowledge Base: What the EU AI Act Actually Asks of You

By Philippe Dallaire • June 2, 2026 • 9 min read
When Your AI Touches SAP, Salesforce, and the Knowledge Base: What the EU AI Act Actually Asks of You

For most of 2024 and 2025, the EU AI Act was a calendar entry — something for legal to map before the deadlines that rolled out toward 2027. In 2026 that distance has collapsed. The transparency rules land in August. The General-Purpose AI provisions are already live. And the technical standards under mandate M/613 — the prEN 18228, 18229 and 18282 series that turn the Act’s abstractions into engineering requirements — are moving through the European standards bodies, with completion targeted for late 2026.

So the question has changed. It is no longer “will the AI Act apply to us?” It is “which obligations fire the moment our agent reads a Salesforce record, posts an invoice into SAP, or pulls a document from the knowledge base?”

The answer is more uncomfortable than most boards expect.

Every connection multiplies your regulatory surface

A recent working paper by Nannini and colleagues — AI Agents Under EU Law: A Compliance Architecture for AI Providers (April 2026) — makes the point cleanly. The regulatory profile of an enterprise AI deployment is not set by the model underneath it. It is set by three operational variables: the domain the agent works in, the type of external action it performs, and whose rights those actions touch.

That has a direct consequence for anyone wiring AI across SAP, CRM, knowledge bases, and the rest of the corporate stack: each connection adds regulatory weight.

  • A customer-service agent reading order history from a CRM already implicates the AI Act’s transparency rules (Article 50) and GDPR.
  • Feed that same agent into a credit decision and it crosses into Annex III high-risk territory, triggering the full weight of Chapter III.
  • An agent posting invoices to SAP touches GDPR for vendor data — and becomes high-risk the moment it influences a creditworthiness assessment.
  • An agent that screens CVs or ranks candidates is high-risk by default — and that classification holds regardless of how you describe the technology.

Connect enough systems and you light up most of a regulatory stack few enterprise architectures were built for: the AI Act, GDPR, the Data Act, the Digital Services Act, PSD2 for payment flows, NIS2 and the Cyber Resilience Act for the infrastructure underneath, and sector regimes like MiFID II for anything that brushes against investment advice.

The blocker nobody is talking about: behavioural drift

Buried in the paper is a finding that deserves far more attention than it has had. High-risk agentic systems that exhibit untraceable behavioural drift cannot currently satisfy the essential requirements of the AI Act.

In plain language: if your AI changes how it acts over time, and you cannot reconstruct why it made a specific decision on a specific record, you may not be deployable in a high-risk function at all.

This is not a paperwork problem. It is an architectural one.

Most enterprise agents in production today run on a tool-calling pattern where the language model decides what to do and generates the actions that execute against your systems. When such an agent updates a Salesforce record, the audit trail is two things: a model trace, which is opaque, and a record of the API call, which has already lost the reasoning that produced it. Fine for low-stakes work. For anything the Act treats as high-risk, it is a structural compliance failure waiting to be found during a conformity assessment.

So the paper’s most useful conclusion isn’t about picking a model or a vendor. It is this: your foundational compliance task is not classification — it’s an exhaustive inventory of the agent’s external actions, data flows, connected systems, and affected persons. Build that inventory first. Then choose the technology that can honour it.

The 2026 tooling landscape — and the gap in the middle

The market has answered with four broad categories, each covering a different slice of the problem.

Dedicated AI governance platforms. Credo AI, Holistic AI, Saidot, Trustible, Fairly AI — model inventory, risk classification against the Act’s tiers, and conformity documentation (notably the Annex IV technical file). Strongest at the policy-and-paperwork layer.

Hyperscaler and enterprise-suite governance. IBM watsonx.governance, Microsoft Purview with Azure AI, Google Vertex AI governance, ServiceNow, and SAP’s own AI governance modules — compliance controls baked into platforms you already run. Their edge is proximity to the data; their limit is that they tend to govern only the AI built inside their own walls.

GRC platforms with AI modules. OneTrust, LogicGate, Vanta, Drata — AI controls bolted onto the GDPR and ISO 27001 modules you already operate. Ideal if you run compliance from a GRC system and want to extend it.

Model-assurance tooling. Robust Intelligence, Fiddler, Arthur, and a growing open-source ecosystem — bias testing, robustness, drift detection. Essential for the dossier, but on its own it does not produce a compliant deployment.

What’s conspicuously under-served is the execution layer itself: the architecture by which an agent actually performs work against SAP, Salesforce, SQL databases, and document repositories in a way that is auditable by construction rather than after the fact.

The right approach: the AI decides, the code executes

This is the gap worth designing against, and it is the same pattern we keep coming back to: separate cleanly what the AI decides from what the system executes.

The model does not write directly into the CRM or the ledger. It proposes a structured decision — JSON, say — describing what it wants to do, on which data, and with what justification based on what it consulted. Deterministic code then validates, executes, and logs the operation. The rules are no longer frozen: the AI can consult them, adapt them to context, even modify them when the data warrants — but every change is documented and reviewable by a human.

You get both properties at once: the flexibility of LLM reasoning over messy real-world data, and the auditability of conventional software. Because every entry that lands in SAP or Salesforce was placed there by inspectable code following a logged decision.

This is precisely what ContentAtlas, built by Consuly, is designed to do. It connects to SAP, Salesforce, SQL databases, Excel, and a long tail of API sources, and turns enterprise data into clean operational pipelines — but it structures the AI’s work as auditable decisions rather than direct writes. The model proposes the transformation, mapping, deduplication, or validation; the system executes it through code; every decision can be traced to its source, edited, reversed, or improved.

The “untraceable behavioural drift” the Nannini paper flags as a structural blocker is exactly what an LLM-decides / code-executes split is built to neutralise. If the model’s reasoning is logged, the code path is fixed, and the resulting data mutation is recorded, the conformity dossier writes itself.

Be clear about what this is and isn’t. It is not a replacement for governance platforms — you still need risk classification, technical documentation, post-market monitoring, and human oversight. It is the complement at the execution layer that makes the evidence those platforms demand possible to produce. And it is worth treating marketing absolutes — “100% conformity” and the like — with the skepticism they deserve. No software guarantees legal conformity on its own; conformity depends on classification, process, governance, and human oversight as much as on technology.

A concrete action plan

Inventory first. Map every system the agent will touch, every type of action it can perform, every data flow it joins, and every category of person whose rights could be affected. This single document determines almost everything downstream.

Classify each path by risk. The same agent can be limited-risk in one workflow and high-risk in another. Identify the highest tier any foreseeable use reaches, and design to that standard — or technically and contractually restrict use so the high tier is genuinely unreachable.

Instrument before you scale. Never widen an agent’s footprint without full traceability already in place. Skip it and you are accruing compliance debt that detonates at the first incident.

Separate decision from execution. For anything that writes to a system of record, never grant the model direct write permissions. The decision comes from the AI; execution goes through code; the rules stay editable and auditable.

Plan for standards still in motion. The prEN 18228/18229/18282 series will translate the Act’s broad obligations into concrete technical requirements through the second half of 2026. Whatever you choose now should bend to accommodate what those drafts finally specify.

An opportunity, not just a risk

The businesses that navigate the next eighteen months well will not be the ones that pick the perfect compliance platform. They will be the ones that recognise the EU AI Act is, at its core, asking a single question of every enterprise AI deployment: can you show your work?

The vendors and architectures that make answering “yes” a property of the system — rather than a project for the legal team — are the ones that scale. Rules before rows. Review before run. Reverse on demand.

Everything else comes down to luck. And luck is not a compliance strategy.

Sources

Academic and analytical work

  • Nannini et al., AI Agents Under EU Law: A Compliance Architecture for AI Providers (April 2026) — working paper on the regulatory profiling of agentic AI systems and the “untraceable behavioural drift” blocker.

EU legislation (AI Act)

  • Regulation (EU) 2024/1689 (Artificial Intelligence Act), in force August 1, 2024, applicable from August 2, 2026 for most high-risk provisions.
  • Article 50 (transparency obligations), Annex III (high-risk use cases), Chapter III (requirements for high-risk systems), Annex IV (technical documentation).
  • Official text and AI Act Explorer: https://artificialintelligenceact.eu

Standardisation (Mandate M/613)

  • prEN 18228, prEN 18229 and prEN 18282 — harmonised standards under development by CEN-CENELEC to operationalise the AI Act’s requirements, completion targeted late 2026.

Adjacent EU regimes referenced

  • Regulation (EU) 2016/679 (GDPR). Official text on EUR-Lex: https://eur-lex.europa.eu/eli/reg/2016/679/oj
  • Data Act, Digital Services Act, PSD2 (payment services), NIS2 (network and information security), Cyber Resilience Act, and MiFID II (markets in financial instruments).

Tools mentioned

  • ContentAtlas by Consuly: https://consuly.ai
  • AI governance platforms: Credo AI, Holistic AI, Saidot, Trustible, Fairly AI.
  • Enterprise-suite governance: IBM watsonx.governance, Microsoft Purview / Azure AI, Google Vertex AI, ServiceNow, SAP AI governance.
  • GRC platforms: OneTrust, LogicGate, Vanta, Drata.
  • Model-assurance tooling: Robust Intelligence, Fiddler, Arthur.

Related Consuly analysis

This article is for informational purposes and does not constitute legal advice. For an analysis of your specific situation under the rules that apply to you, consult qualified legal counsel.

More to Read