AI on your SAP data,
within the framework of the AI Act
Knowledge
What we learn from the audits, we build in.
Reading the regulation is one thing, establishing how it applies within a specific SAP environment is another.
Each audit shows where the boundary runs in practice and where organisations encounter difficulty in evidencing their position.
That understanding determines what Thor must be capable of. Individual findings remain with the client.
Digital assistant
Thor 1.0 is the digital assistant we intend to build for organisations that wish to automate following the audit.
It operates on the data already held in your SAP environment and records, for each processing operation, what took place: which system, which data, which decision.
That is what you need to be able to present to a supervisory authority.
Our starting point
We deliberately begin with a single environment. SAP holds the data behind decisions the AI Act treats most strictly: personnel, credit and supplier decisions.
One environment means one set of integrations to secure and one data flow to document.
We will extend to other environments only once the same safeguards can be demonstrated there.
What Thor should deliver in your SAP environment
This is what we are building towards
A current overview of which AI applications are active in your SAP environment, without anyone maintaining a list by hand
An audit trail for every processing operation: which system, which data, which outcome
Automation that runs on your own data, without that data leaving the environment
Documentation that keeps pace with the environment, rather than a snapshot that goes out of date
SAP integration
Designed for your existing SAP environment
DataNerds is a member of SAP PartnerEdge, Build, the partner track for developers of software that runs on SAP technology.
Thor is being designed to work within an existing SAP S/4HANA environment, not to replace it.
Our engineers build the two-way connectors between your SAP environment and the isolated processing environment. Your data model stays as it is, and nothing is migrated.
How Thor is built
Base model
Mistral Small 3, a European open-weight model. No API calls to an external provider.
How Thor fits your process
The model is aligned to your SAP structures and to the requirements of the AI Act and the GDPR through Group Relative Policy Optimisation. Those regulatory requirements are built into the alignment of the model itself, not into a filtering layer around it.
Hardware
GPU capacity and storage leased in LCL's data centres in Belgium, in containerised clusters.
Network
A deployment isolated from the internet. It is designed so that data does not leave the perimeter.
Access
Model weights, tuning logs and data flows sit on infrastructure you can inspect yourself. An auditor can verify that directly, rather than relying on a provider's attestation.
The thresholds are fixed before the first tuning run, together with the baseline measurement on historical invoices with known outcomes. That way the result cannot be adjusted to fit afterwards.
Error rate: below 8% on the test set.
Retained reasoning ability: no more than 3 percentage points of degradation on general benchmarks.
An error means the system flags a discrepancy that is not there, or misses one that is. A missed discrepancy reaches the same human check that is in place today. A false alert only costs time.
The setup will be reviewed independently, including a penetration test. That independence is deliberate: a review we carried out ourselves would carry no evidential weight.
Thor is not a plug-and-play service. Setting up the connectors and the isolated environment makes onboarding heavier than with a cloud service. At low volumes, the fixed cost of a dedicated environment does not justify the benefit.
Because it is tuned for SAP data and regulatory work, the model performs less well on general or creative tasks. If you are looking for a broad assistant for writing and analysis, a public service will suit you better.
The central technical hypothesis is also still unproven. If the model cannot be tuned without losing reasoning ability, part of the proposition falls away. We will publish that outcome either way.
Development starts in November 2026 and runs for six months. The work is split into three work packages with fixed decision points: commercial validation, model tuning, and integration with SAP S/4HANA. At each decision point, the criteria for continuing, adjusting or stopping are set in advance.
We work with large enterprises in Belgium that already run SAP. Typically manufacturing, financial services and distribution: organisations with thousands of employees, multiple entities and processes that have been running for years. There, automation does not sit in isolated experiments but in systems that produce decisions every day.
These organisations generally have an IT department, a DPO and a governance structure in place. What is usually missing is not policy, but visibility into what is actually running and where it comes from.
Interested in the pilot?
We are looking for organisations with an SAP S/4HANA environment who are willing to help validate the first use case. That starts with an audit, because without an inventory and classification we do not know what is running in your organisation.
