Providers and deployers of high-risk AI must keep every LLM call traceable — while GDPR limits PII retention. How to honour both at once with source-side PII redaction and signed evidence packs.

The EU AI Act is in force. Article 12 requires providers and deployers of high-risk AI systems to keep automatic logs of how the system operates. But what does that mean concretely if you're already using AI in your business processes today?

This article is not a legal interpretation — you'll need a lawyer or DPO for that. What it does give you: a concrete overview of which logging obligations apply, which organisations they apply to, and how to implement it technically.

Who falls under Article 12?

The AI Act distinguishes between providers (who put AI systems on the market) and deployers (who use AI systems in a professional context).

Providers of high-risk AI systems (defined in Annex III of the AI Act) must produce technical documentation and keep logs of operation.

Deployers using high-risk AI must:

Keep logs of usage
Implement human oversight
Be able to investigate complaints by reconstructing individual decisions

High-risk applications (Annex III) include, among others:

Biometric identification
AI in critical infrastructure
AI in education and vocational training
AI in personnel selection (CV screening, application assessment)
AI for access to essential services (credit, insurance)
AI in law enforcement
AI in migration and border control
AI in administration of justice

Important: even if you have no high-risk system, there are transparency obligations (Article 50) and GDPR processing obligations when you process personal data via LLMs.

What Article 12 concretely asks

Article 12(1): "High-risk AI systems shall technically allow for the automatic recording of events ('logs') over the lifetime of the system."

In practice this means:

What input was given to the AI system
What the output of the system was
When the interaction took place
Who was involved (user session, not necessarily a name)
Which model was used

The GDPR complication: PII in LLM calls

Here it gets practically complicated. If you use an LLM for customer service and end users include personal data in their messages — an IBAN for a balance question, a patient number for a care question, an application number for an HR question — then you are obliged to:

Log that data for AI Act traceability
Not store that data unsecured for GDPR purposes
Document a data transfer if the LLM provider is established outside the EU (OpenAI, Anthropic, Google)

These three obligations conflict unless you address them explicitly.

The monsys approach: PII redaction at the source, before storage. The SDK recognises IBAN, national registry number, BTW-BE, KBO, NL BSN, FR NIR, e-mail addresses and phone numbers via checksum validation and replaces them with [REDACTED-IBAN-BE] before the HTTP POST leaves for the hub. The hash of the original remains available as evidence ("same IBAN as in span Y") without the original being stored anywhere.

AI observability overview in monsys The AI page shows per app the volume, cost, pii-hit-rate, refusal-rate and alert status. All based on redacted data.

Scenario: HR recruitment AI under AI Act Article 6

You use Claude to pre-screen CVs for open positions. That is high-risk AI (Annex III, point 4).

What you must be able to demonstrate:

For every candidate: which input was given to the AI system
Which output (assessment, score, recommendation) the system gave
That a human made the final decision (Art. 14)

Practical problem: a candidate files a complaint via the Data Protection Authority. She wants to know why her CV was rejected.

Without AI observability: you must manually search through deployment logs, prompt configurations and Git history to reconstruct what the system saw and said. That takes days and the chance of completeness is low.

With monsys AI observability: filter traces by user_session_hash of the candidate, unlock content via TOTP (one-shot, logged), and reconstruct the exact prompt and response within five minutes. Article 14 human oversight: the operator handling the complaint is the human in the loop.

Scenario: customer-service chatbot and FSMA

You have an AI chatbot answering balance questions for clients of a financial institution. FSMA comes asking: prove that the bot never exposed IBAN numbers of other clients.

Without logging: you cannot prove this. At most you can say the system is configured such that it shouldn't happen.

With monsys: each span carries pii_hits with hashes of redacted PII. A monthly evidence pack contains an aggregated report.

python verify.py evidence_bank-bv_april-2026.tar.gz
✓ Signature valid (Ed25519)
✓ 2847 spans intact
✓ PII summary: 312 IBAN hits, all redacted
exit 0

The FSMA inspector has an offline-verifiable artifact. No dashboard access required, no trust-our-claim.

Scenario: cost-spike prevention

A developer pushes a new RAG prompt with a bug: they accidentally include the full documentation database as context in every call. Every prompt is suddenly 50KB instead of 2KB.

Without monitoring: you discover this on the monthly OpenAI bill. Damage: €2,000-5,000.

With monsys: a cost-spike alert fires within 15 minutes when cost_per_minute > €1 (configurable). Push notification via ntfy on your phone. The developer rolls back the bug. Damage: €4-8.

This is no compliance advantage but a direct financial one. AI costs are volatile and hard to budget without monitoring.

What monsys does and doesn't do for AI Act compliance

What monsys delivers:

Automatic logs of every LLM call (AI Act Art. 12)
Source-side PII redaction with checksum validation (GDPR)
Signed evidence packs, offline verifiable (for regulators)
Per-session reconstruction of prompts and completions via TOTP-gated unlock (AI Act Art. 14)
EU hosting (no data transfer outside EU for stored traces)
Alerts on cost spikes, refusal-rate increases, PII-rate anomalies

What monsys does not do:

Make you NIS2 or AI Act compliant (that is an organisational process, not a product)
Replace a DPIA (Data Protection Impact Assessment)
Block prompt injection inline or provide guardrails
Detect whether your system is fair or discriminates (requires other tooling)
Guarantee what OpenAI/Anthropic/Mistral does with your data

The honest message: AI Act compliance is a combination of legal analysis, organisational processes and technical tooling. monsys delivers the technical tooling for the logging obligation. The rest is up to you.

Integration in three steps

Step 1: Create an AI app in the dashboard. The token is shown once.

Step 2: Drop the SDK next to your LLM call. Example in Python:

from monsys_ai import Tracer
tracer = Tracer()  # reads MONSYS_AI_TOKEN from env

def process_customer_request(user_message: str, session_id: str) -> str:
    with tracer.trace(f"customer_service.{session_id}") as t:
        with t.span("claude.respond", provider="anthropic", model="claude-sonnet-4-6") as s:
            s.prompt = user_message
            response = claude_client.messages.create(
                model="claude-sonnet-4-6",
                messages=[{"role": "user", "content": user_message}]
            )
            s.completion = response.content[0].text
            s.input_tokens = response.usage.input_tokens
            s.output_tokens = response.usage.output_tokens
            return s.completion

Step 3: Review traces in the dashboard. Set cost alerts. Export a signed evidence pack monthly.

First AI app free per tenant. No credit card for the first 5,000 traces per month.

AI observability is documented at docs.monsys.ai/en/ai/quick-start. Start free: monsys.ai/en/ai.

AI Act Article 12: what you need to log when you use AI in a business process