Fully Auditable: Why wals.pro AI 4 weclapp Also Works for Compliance Teams

In every workshop, the same question arises, and it almost always comes from the person with the most responsibility in the room. Most often it is the IT manager, sometimes the managing director, occasionally the data protection officer. The question is: And who controls what the AI is actually doing?

That is the right question. It deserves a full answer, not just reassurance.

Since 2019, as a certified weclapp partner from Vienna, we have been building weclapp integrations for trade, production, and services. On our wals.pro AI 4 weclapp platform, more than 50 companies now control their weclapp via AI, with over 5,000 AI actions in 30 days from real production clients. Four out of five accesses are read-only. This article describes what happens with the fifth.

Control is not a checkbox, but the process

The most important difference first: control at wals.pro AI is not a setting that you can find deep in the options and activate. It is the path that every single action takes. There is no mode in which an action shortens this path, and there is no setting that deactivates it.

The path has four stations: Authorization, Preview, Release, Log.

Station 1: Who is allowed to do what

Before a question is answered, it is determined who is allowed to ask it. The platform knows three roles: Viewer, Editor, and Admin, and below that, policies per person. A read switch determines whether someone can read at all. Entity scopes define which data areas are visible. An action allowlist determines, action by action, what someone is allowed to write.

The default is: read-only. Write permissions do not arise from inaction but from a conscious decision.

Practically, this means: Sales creates offers but does not change prices. Accounting assigns payments but does not create orders. The warehouse books goods receipts but does not see contribution margins. For compliance teams, this is precisely the decisive point: the AI does not generally inherit the rights of an API key but operates within the rights of the person currently using it.

Station 2: The preview that changes nothing

Every write action begins with a preview. It is not a summary or a declaration of intent, but the complete plan: which document will be affected, which items with which values, which default values the platform has resolved, which warnings are pending. Field by field, item by item.

This preview changes nothing. It reads, it calculates, it reveals. Anyone who ignores it and closes the window leaves no half-written document.

Where the situation is ambiguous, the platform does not decide on its own but aborts and asks for clarification. Where values are implausible, such as a shipping date in the future, it rejects them instead of accepting them.

Station 3: The one-time release, tied to exactly these values

A release token is created from the preview, and this token is the core of the entire construct. It is tied to the action, to the target document, and to an SHA-256 hash of the payload data.

What this means becomes clear at the boundary cases. If even a single character in the data changes between preview and execution, the hash no longer matches, and the execution is rejected. The token is short-lived and valid exactly once. If someone tries to use it a second time, for example after a network timeout or a hectic second click, they receive the logged result of the first run instead of booking a second time. Double bookings are thus structurally excluded, not just unlikely.

A release therefore applies to exactly this action with exactly these values, only once. It is not permission for the future. There is no way to turn it into a permanent state.

We deliberately phrase one point precisely: payload-bound one-time releases via SHA-256. Not HMAC. Those who review security statements also review the terms.

Station 4: The log, on two levels

This is where it gets interesting for auditors, because two log levels interact.

The first is the platform's audit log. Every call is recorded there: who, when, which action, what result. Not just the successful ones. A call that fails due to missing authorization is also a result and is also logged. From the Pro tariff onwards, this log can be exported.

The second level is within weclapp itself. Every change made via the platform also ends up in your client's activity log, i.e., where changes from the interface are also located. The platform can also read this log: filtered by document type, by individual document, by event type, by time period, across around 37 document types and more than a hundred event types. So you can ask your assistant what happened to a specific order in the last four weeks, and you will get the answer from the log, not from a reconstruction.

For an audit, this means: The AI is not a blind spot in the document chain. It is the best documented.

What the platform deliberately cannot do

Just as revealing as the feature list is the list of what is missing, and deliberately so.

There are no delete functions for business data in the tool interface. An AI cannot destroy a document with us. Corrections are made via the mechanisms that weclapp itself provides for this: cancellation, reset, versioning. A revised offer receives a new version under the same number; the previous one remains traceable. The document chain thus remains complete instead of getting gaps.

Access data is made unreadable server-side before it leaves the platform. Fields such as API keys, passwords, tokens, or access URLs are returned redacted, even if someone explicitly requests them. Email accounts only provide a fixed, harmless subset of fields; mailbox addresses and calendar tokens are not included.

Personal reference in the log is off by default. If you want to see the acting person in the activity log, you must actively request it.

And read accesses are capped. The log comprises millions of lines; queries deliver limited, chronologically sorted excerpts. An assistant cannot accidentally pull half the client into context.

Where the data is located and who has which contract

Hosting is in the EU, in the europe-west1 region, with strict client separation. Registration is via OAuth 2.1; connected AI clients are visible in your account and can be revoked at any time.

We deliberately make one point clear because it often goes unnoticed until late in security reviews: wals.pro AI does not come with its own language model. We operate the secure execution layer to weclapp. What your assistant reads is processed by your AI provider under your contract with them. That's why we say EU hosting, and not EU-only in the absolute sense. For the review, this is good news: the contractual situation remains where it is already regulated, and the access layer to your ERP comes from the EU.

For environments with increased compliance requirements

If you work in a more regulated environment, in food or pharmaceutical logistics, in medical device trading, in the financial accounting of an audited corporation, then we recommend the same entry point that our customers already choose most frequently.

Start with read-only access. This covers searching and evaluating over approximately 145 weclapp entities and is the part with the fastest benefit and lowest risk. Let your team get familiar with the previews. Then enable individual write actions, per person and per action, where the benefit is greatest and the document is least critical. Payment assignment and offer creation are good first candidates; inventory bookings come later.

And bring the audit on board before the first write operation runs. The material for this is available: role model, release mechanism, audit log, hosting. Experience shows that the conversation is short if the answers are already available in writing.

What customers say about it

"The game changer for weclapp."

Kurt Liebenberg, Managing Partner at BQM

"I am thrilled with how structured and clean AI agents can create and manage offers, orders, and purchase orders. It's an enormous relief for my employees."

Marcel Sohn, Head of Sales D/A/CH at SEIKOM-Electronic

How to get started

wals.pro AI 4 weclapp is currently in open beta and can be used for free until December 31, 2026, with all features. You need a weclapp client, an AI assistant of your choice, and half an hour.

The most honest test is a test client: create access, connect read-only, ask real questions for a week, and then check the audit log. It will show exactly what happened: ai.wals.pro

If your audit has specific questions about data processing agreements, role models, or log export, then bring them to an appointment. We will answer them based on a concrete case rather than a data sheet: wals.pro/termin