Your compliance records are missing your AI traffic

You have log entries for HR and CRM, but not the prompts going to OpenAI/Anthropic or Mistral. But your team may sends EU customer data to OpenAI every day. Where's the record?

TL;DR: Every European / operating in EU company shall maintain a Record of Processing Activities. Almost none of them have an entry for the prompts their teams send to OpenAI, Mistral or Deepseek every day — the fastest-growing processing activity in the building. You declare ten lines of YAML once in Dativo Talon; everything else is derived from records a consultant cannot fabricate. There’s a downloadable sample pack you can hand to a reviewer today.

Photo by Zulfugar Karimov on Unsplash

A friend of mine runs platform engineering at a ~200-person B2B company in Germany. Earlier this year they were closing their biggest deal to date - enterprise customer, everything agreed except the security review.

Question 47 of the enterprise questionnaire shared in long excel: “Describe how personal data in AI/LLM workflows is governed, including records of processing, sub-processors, and third-country transfers.”

He took it to their CTO. The CTO opened their information systems register, the register every European company is required to keep under GDPR Article 30( called there Record of Processing Activities - RoPA) - it can be as simple as confluence, and found entries for the HR system, the CRM, the email marketing tool. Nothing about the support bot that had been summarizing customer tickets through AI for eight months. Oops.

“Where do our prompts go?” CTO asked. In theory , the knew that the support bot they purchased use OpenAI’s ChatGPT, but nobody in the room could answer with evidence where the prompts went and what was inside the prompts. There were logs, somewhere, spread across three SaaS dashboards. There was no record.

The deal closed five weeks late - five weeks of a platform engineering and a CTO reverse-engineering their own AI usage so they could write it down and have legal sign it. That’s the moment AI governance stops being a legal abstraction and becomes a sales blocker.

Why AI traffic belongs in your Record of Processing Activities ( EU focused part)

If you’re the engineer, focusing on EU, who has to answer question 47, here’s the 90-second version of what’s being asked.

The Record of Processing Activities - RoPA (GDPR Art. 30) is a register that answers, per processing activity: what personal data do we process, why, about whom, who receives it, does it leave the EU, how long do we keep it, and how is it protected? It’s mandatory for nearly every European company. There’s a nominal under-250-employee exemption, but it doesn’t apply when processing is “not occasional” — and a support bot running every day is by definition not occasional. The RoPA is the first document requested in a regulator inquiry, an ISO 27001 surveillance audit, and most enterprise security reviews. Art. 30 violations sit in the fine tier of up to EUR 10M or 2% of global turnover.

Annex IV (EU AI Act) is the technical documentation required for high-risk AI systems: what the system is, how it’s monitored and controlled, how risks are managed, how humans oversee it. High-risk obligations apply from August 2, 2026. Most mid-size companies are deployers rather than providers, which means lighter obligations — but the documentation demand flows down through contracts anyway. Your enterprise customers will ask you to evidence your usage controls, oversight, and logging regardless of your formal role. Documentation-tier violations run up to EUR 15M or 3% of turnover.

AI traffic is the gap in both documents. Companies have RoPA entries for systems built ten years ago, while prompts flowing to a US model provider — a new processing activity, with a new recipient, and often a third-country transfer — go unrecorded. It’s exactly the thing CTO/Legal/Compliance are now being asked about, and exactly the thing they can’t answer from scattered logs.

Here’s what I realized while building Talon’s gateway: the network layer already knows the answers. Which PII categories were observed in prompts. Which provider received them, in which region. What was redacted, what was blocked, what it cost. Talon records all of that per request, HMAC-signed at write time.

Some consultant writing your RoPA guesses at these facts. The gateway proves them.

Declared + derived: ten lines of YAML, then evidence does the rest

Declared facts are business statements no log can know: who the controller is, why you process data, how long you keep it. Your DPO writes them once. Org-level identity goes in talon.config.yaml:

compliance:
  controller:
    name: "Example GmbH"
    contact: "privacy@example.eu"
    dpo_contact: "dpo@example.eu"
    address: "Examplestr. 1, 10115 Berlin, Germany"

Per-agent declarations live in agent.talon.yaml, next to the policy that governs the agent:

compliance:
  frameworks: [gdpr, eu-ai-act]
  data_residency: eu
  declarations:
    processing:                      # GDPR Art. 30(1) facts
      purposes:
        - "customer support ticket triage"
      data_subject_categories:
        - "customers"
      personal_data_categories:
        - "contact details"
        - "payment identifiers"
        - "support ticket content"
      retention_period: "90 days after ticket closure"
      legal_basis: "contract (Art. 6(1)(b))"
      safeguards: "Role-based access; vendor DPAs on file; signed evidence retained for audit review"
    system:                          # EU AI Act Annex IV facts
      system_description: "Gateway-governed LLM assistant for support ticket triage"
      intended_purpose: "Summarize and route inbound support tickets"
      oversight_description: "Support lead reviews flagged tickets daily"

Derived facts come from the signed evidence store, and you never write them by hand: which processing activities actually ran (per tenant, per agent, first seen, last seen), which personal-data identifiers were actually observed, which recipients received data and in which region, which requests were third-country transfers, which policy denials fired, and which requests went through a human plan-review gate.

One design decision matters more than it looks: every governed request records where it went — not just the ones where PII was detected. A recipient list that depends on a classifier’s hit rate is a recipient list with silent holes; a missed identifier should never make a US provider disappear from your transfer table. Talon records the prompt → destination flow (provider, model, region) for all traffic — gateway requests, CLI and scheduled agent runs, MCP tool calls, and externally orchestrated graph runs — and layers the sensitivity classification on top. The rule “a record claiming a model call must say where the data went” is enforced as a runtime invariant on every evidence write, in CI by a parity contract test, and in the release smoke suite. The full controls-per-path breakdown is in the governance control matrix.

Then one command merges declared and derived facts into each document:

talon compliance ropa --format html --output ropa.html
talon compliance annex-iv --format html --output annex-iv.html

The HTML is print-to-PDF-ready. The JSON variant is machine-checkable, for the security reviewers who want to diff it between quarters.

Missing declarations are flagged, not hidden

Your GDPR RoPA Is Missing Your AI Traffic — Here’s How to Fix It With Runtime Evidence

TL;DR: Every European company maintains a Record of Processing Activities. Almost none of them have an entry for the prompts their teams send to OpenAI every day — the fastest-growing processing activity in the building. Dativo Talon, an open-source AI governance gateway, now generates a GDPR Art. 30 RoPA and an EU AI Act Annex IV documentation pack directly from HMAC-signed runtime evidence: talon compliance ropa and talon compliance annex-iv. Your compliance officer declares ten lines of YAML once; everything else is derived from records a consultant cannot fabricate. There’s a downloadable sample pack you can hand to a reviewer today.

---

A friend of mine runs platform engineering at a ~400-person B2B company in Germany. Earlier this year they were closing their biggest deal to date — six figures, enterprise customer, everything agreed except the security review.

Question 47 of the questionnaire: “Describe how personal data in AI/LLM workflows is governed, including records of processing, sub-processors, and third-country transfers.”

He took it to the compliance officer, who opened the company’s RoPA — the register every European company is required to keep under GDPR Article 30 — and found entries for the HR system, the CRM, the email marketing tool. Nothing about the support bot that had been summarizing customer tickets through GPT-4 for eight months.

“Where do our prompts go?” the compliance officer asked. Nobody in the room could answer with evidence. There were logs, somewhere, spread across three SaaS dashboards. There was no record.

The deal closed five weeks late — five weeks of a platform engineer and a compliance officer reverse-engineering their own AI usage so they could write it down and have legal sign it. That’s the moment AI governance stops being a legal abstraction and becomes a sales blocker.

Why AI traffic belongs in your Record of Processing Activities

If you’re the engineer who has to answer question 47, here’s the 90-second version of what’s being asked.

The RoPA (GDPR Art. 30) is a register that answers, per processing activity: what personal data do we process, why, about whom, who receives it, does it leave the EU, how long do we keep it, and how is it protected? It’s mandatory for nearly every European company. There’s a nominal under-250-employee exemption, but it doesn’t apply when processing is “not occasional” — and a support bot running every day is by definition not occasional. The RoPA is the first document requested in a regulator inquiry, an ISO 27001 surveillance audit, and most enterprise security reviews. Art. 30 violations sit in the fine tier of up to EUR 10M or 2% of global turnover.

Annex IV (EU AI Act) is the technical documentation required for high-risk AI systems: what the system is, how it’s monitored and controlled, how risks are managed, how humans oversee it. High-risk obligations apply from August 2, 2026. Most mid-size companies are deployers rather than providers, which means lighter obligations — but the documentation demand flows down through contracts anyway. Your enterprise customers will ask you to evidence your usage controls, oversight, and logging regardless of your formal role. Documentation-tier violations run up to EUR 15M or 3% of turnover.

AI traffic is the gap in both documents. Companies have RoPA entries for systems built ten years ago, while prompts flowing to a US model provider — a new processing activity, with a new recipient, and often a third-country transfer — go unrecorded. It’s exactly the thing compliance officers are now being asked about, and exactly the thing they can’t answer from scattered logs.

Here’s what I realized while building Talon’s gateway: the network layer already knows the answers. Which PII categories were observed in prompts. Which provider received them, in which region. What was redacted, what was blocked, what it cost. Talon records all of that per request, HMAC-signed at write time.

A consultant writing your RoPA guesses at these facts. The gateway proves them.

Declared + derived: ten lines of YAML, then evidence does the rest

Every auditor document splits into two kinds of facts, and Talon’s design keeps them strictly separate.

Declared facts are business statements no log can know: who the controller is, why you process data, how long you keep it. Your compliance officer writes them once. Org-level identity goes in talon.config.yaml:

compliance:
  controller:
    name: "Example GmbH"
    contact: "privacy@example.eu"
    dpo_contact: "dpo@example.eu"
    address: "Examplestr. 1, 10115 Berlin, Germany"

Per-agent declarations live in agent.talon.yaml, next to the policy that governs the agent:

compliance:
  frameworks: [gdpr, eu-ai-act]
  data_residency: eu
  declarations:
    processing:                      # GDPR Art. 30(1) facts
      purposes:
        - "customer support ticket triage"
      data_subject_categories:
        - "customers"
      personal_data_categories:
        - "contact details"
        - "payment identifiers"
        - "support ticket content"
      retention_period: "90 days after ticket closure"
      legal_basis: "contract (Art. 6(1)(b))"
      safeguards: "Role-based access; vendor DPAs on file; signed evidence retained for audit review"
    system:                          # EU AI Act Annex IV facts
      system_description: "Gateway-governed LLM assistant for support ticket triage"
      intended_purpose: "Summarize and route inbound support tickets"
      oversight_description: "Support lead reviews flagged tickets daily"

Derived facts come from the signed evidence store, and you never write them by hand: which processing activities actually ran (per tenant, per agent, first seen, last seen), which personal-data identifiers were actually observed, which recipients received data and in which region, which requests were third-country transfers, which policy denials fired, and which requests went through a human plan-review gate.

One design decision matters more than it looks: every governed request records where it went — not just the ones where PII was detected. A recipient list that depends on a classifier’s hit rate is a recipient list with silent holes; a missed identifier should never make a US provider disappear from your transfer table. Talon records the prompt → destination flow (provider, model, region) for all traffic — gateway requests, CLI and scheduled agent runs, MCP tool calls, and externally orchestrated graph runs — and layers the sensitivity classification on top. The rule “a record claiming a model call must say where the data went” is enforced as a runtime invariant on every evidence write, in CI by a parity contract test, and in the release smoke suite. The full controls-per-path breakdown is in the governance control matrix.

Then one command merges declared and derived facts into each document:

talon compliance ropa --format html --output ropa.html
talon compliance annex-iv --format html --output annex-iv.html

The HTML is print-to-PDF-ready. The JSON variant is machine-checkable, for the security reviewers who want to diff it between quarters.

Missing declarations are flagged, not hidden

This is the part I care most about as an engineer, and the part I would never bury in a demo screenshot.

If a declaration is missing, the command doesn’t fail — it renders a flagged DECLARATION MISSING section and prints exactly which YAML field to set. The document itself becomes the to-do list for your compliance officer. Talon fills what can be proven from signed evidence and clearly flags what must be declared by your organisation. That’s a far more trustworthy compliance story than “one-click compliance,” and it’s the kind of behaviour a compliance officer will actually trust after the first review.

The same discipline runs through the evidence-derived sections, in both directions:

• No understatement. If no data-flow evidence exists yet, the transfers section says transfers “cannot be assessed yet” — it never converts absence of evidence into a comforting “no transfers” finding.

• No overstatement. When a policy blocks a request, the blocked attempt stays in the signed evidence, but the destination is not listed as a recipient — blocked data never reached anyone. A recipient table that counted blocked traffic would overstate your processing, and a compliance officer would catch it in the first review.

• Redaction is part of the record. An identifier type that was redacted in every flow to a destination is annotated “redacted before egress”; if it ever went through raw, even once, the annotation is withheld. “OpenAI received email addresses” and “OpenAI received placeholders where email addresses used to be” are very different statements to a compliance officer, and the document refuses to blur them.

The document also checks your declarations against reality. If your agent declares data_residency: eu but routing still allows US providers and the evidence shows data actually flowing there, the RoPA prints a consistency warning with the two honest ways out: enforce eu_strict routing, or document the transfer mechanism with your compliance officer. Your own compliance export catches your config drift before an auditor does.

I watched all of this fire on a fresh install, unstaged. The first request I sent was denied at the routing stage — the agent’s policy pointed at a provider that wasn’t configured, so nothing ever left the machine. The denial landed in the signed evidence (POLICY_DENIED_ROUTING, with the fix spelled out in the record), but the RoPA generated from it listed no recipients and said transfers “cannot be assessed yet” — blocked data never reached anyone, so the document refused to invent a recipient. The second request succeeded against OpenAI, and the regenerated document did three things at once: put openai / US in the recipient table, flagged the third-country transfer with the SCC note, and opened with the consistency warning — because the config declared data_residency: eu while the evidence showed traffic reaching a US region:

consistency: compliance.data_residency is declared “eu” but 1 destination(s) outside EU/LOCAL appear in data-flow evidence (Section 6) — set llm.routing.data_sovereignty_mode: eu_strict to enforce EU routing, or document the transfer mechanism (SCCs, adequacy decision) with your DPO

That’s the document doing its job on run two of a brand-new install: catching a real residency gap I hadn’t noticed, and telling me exactly how to close it.

The same evidence answers your security review, not just your compliance officer

Question 47 rarely arrives alone. The same questionnaire that asks about records of processing asks how you prevent data leakage to AI providers, whether your audit logs can be tampered with, and what stops an AI agent from doing something it shouldn’t. Compliance documentation and infosec controls are usually owned by different people and answered from different tools — which is exactly why the answers contradict each other in review.

The reason a gateway can generate your RoPA is the same reason it closes the security gaps: it sits on the network path and enforces policy before data leaves, instead of reporting on it afterwards. Each control produces the same signed evidence the compliance documents are built from:

• Shadow AI and unsanctioned usage. Talon gives AI traffic a single egress point. Every governed request is recorded with tenant, agent, destination, and region — whether or not PII was detected — so “what AI tools is the company actually using?” is a database query, not a survey. Traffic that bypasses the gateway is out of scope by definition, which is also your network team’s argument for routing it through.

• Data leakage to third parties. PII is detected and redacted before egress, and the evidence records both facts separately — input redaction and output redaction are independent claims. API keys never sit in prompts or agent code: they live in an encrypted vault (AES-256-GCM), scoped by per-agent ACLs, and every retrieval is itself an audit record.

• Prompt injection via attachments. File content (PDF, DOCX, HTML) is treated as untrusted by default — wrapped in isolation delimiters, scanned for embedded instructions, and blocked or flagged per policy. Detected injection attempts generate evidence even when the request is blocked.

• Excessive agency. Agents declare allowed tools in agent.talon.yaml; the policy engine filters the tool list before the model ever sees it, and every MCP tool call passes through policy evaluation before execution. A dangerous tool the model never learned about is a class of incident that can’t happen.

• Runaway spend. Per-request, daily, and monthly budgets are enforced at the gateway — a request over budget is denied before any cost is incurred, and the denial is recorded.

• Log tampering. Evidence records are HMAC-signed at write time. A reviewer — or your own incident-response team — can verify the export offline with talon audit verify. An attacker who modifies a record breaks its signature; “the logs say X and we can prove the logs weren’t altered” is a materially stronger incident report.

This is also where the ISO 27001 and NIS2 story gets simple. The evidence store gives you logging and monitoring records (A.8.15), the vault covers cryptographic controls for credentials (A.8.24), the denial trail supports incident management (A.5.24–A.5.26), and NIS2 Art. 21’s risk-management measures get the same answer the compliance officer got: not a policy PDF, but signed records of the controls actually firing. talon compliance report prints the framework-to-control mappings alongside the runtime numbers, so your security lead and your compliance officer are quoting the same document for once.

What manual AI compliance documentation actually costs

If you’re the internal promoter — the platform engineer or CTO who has to convince a compliance officer, a board, or a customer’s security reviewer — here are the reference ranges (EU Commission impact assessment via CEPS, industry cost surveys, 2024–2026; all estimates):

• Annex IV documentation done manually: EUR 15,000–60,000 per high-risk system; consultant-led packages run EUR 50,000–150,000+ over 3–6 months.

• DIY without tooling: EUR 30,000–80,000 in internal staff time — senior engineers writing documentation instead of product.

• RoPA maintenance: compliance-officer and privacy-consultant rates around EUR 800–1,500/day, days per review cycle, and the document goes stale the moment it’s written. Talon regenerates it from live evidence in one command.

• Compliance automation tools: EUR 7,500–80,000/yr — and none of them sit on the network path, so they produce templates, not evidence.

But the biggest number isn’t on that list. For a 200–1,000-employee B2B company, the costliest compliance event isn’t a fine — it’s a stalled enterprise deal. “How is your AI usage governed?” is now a standard security-review question. Handing over a generated, independently verifiable evidence pack converts a five-week back-and-forth into an email attachment. One accelerated deal dwarfs every other line in this analysis.

The honest framing on fines: nobody can promise you “no fines,” and you should walk away from any vendor who does. What I can say is that when a regulator or auditor asks, the organization that produces organized, signed records in minutes is treated very differently from the one that produces nothing in weeks.

What this does not do

Claims discipline matters more in this domain than in any other:

• The output is supporting records for GDPR Art. 30 and EU AI Act Annex IV review — not a completed legal filing, a certification, or “compliance in a box.” Every document says so in its footer.

• Talon only sees the traffic that flows through it. AI usage that bypasses the gateway isn’t in the evidence — the RoPA covers what Talon governs.

• When an external agent framework (LangGraph, LangChain) is governed via Talon’s event API, the content itself never transits Talon — so those flows are recorded as exactly what they are: orchestrator-reported, model named, region unknown. Talon never guesses a jurisdiction. That unresolved region shows up in your transfer table on purpose.

• You still need your compliance officer or counsel to review purposes, legal bases, and transfer mechanisms. The tool eliminates the assembly work — the weeks of reverse-engineering what your AI usage actually is — not the legal judgment.

If a consultant told you a tool could replace them entirely, they’d be lying. If they told you assembling AI processing records by hand is a good use of EUR 1,200/day, they’d also be lying.

Generate your first AI RoPA in ten minutes

The whole point of Talon is that the proof path is short:

# 1. Init (wizard writes both config files, ~2 min)
talon init

# 2. Route a request through the gateway — this creates signed evidence
talon serve --gateway &
curl -s http://localhost:8080/v1/proxy/openai/v1/chat/completions \
  -H "Authorization: Bearer $TALON_TENANT_KEY" \
  -d '{"model":"gpt-4o-mini","messages":[{"role":"user","content":"My IBAN is DE89370400440532013000"}]}'

curl -s http://localhost:8080/v1/proxy/openai/v1/chat/completions \
  -H "Authorization: Bearer $TALON_TENANT_KEY" \
  -d '{"model":"gpt-4o-mini","messages":[{"role":"user","content":"Hello, how are you?"}]}'


# 3. Generate the documents your compliance officer has been asked for
talon compliance report --format html --output compliance-report.html
talon compliance ropa --format html --output ropa.html
talon compliance annex-iv --format html --output annex-iv.html

# 4. Let the reviewer verify the evidence themselves
talon audit export --format signed-json --output evidence.signed.json
talon audit verify --file evidence.signed.json

Open ropa.html. Section 4 already lists the IBAN identifier the classifier caught. Section 5 names the recipient and region — and if redaction was on, marks the IBAN “redacted before egress”: the provider got a placeholder, not the account number. Section 6 flags the third-country transfer with a note to document your SCC or adequacy mechanism. And if your declared residency disagrees with where the evidence shows traffic going, the document opens with the consistency warning from earlier.

If anyone asks about a single request, the answer is one record away — talon audit show <id> prints the per-request data flow in plain text:

PII Detected:  iban
PII Redacted:  input=true output=false
...
Data Flow
  Detector:    talon-regex
  prompt -> llm_provider:openai model=gpt-4o region=US | redacted | tier 1 | iban

Source, destination, region, what was detected, and whether it was redacted before it left — the RoPA’s recipient table, at the granularity of one request. Your compliance officer’s job goes from “reconstruct eight months of AI usage” to “review a document and fill in the fields the export flags.”

Don’t have the gateway running? Even the simplest path works: talon run "hello" against OpenAI is enough to put the provider in Section 5 and the US transfer in Section 6 — no PII required, because data movement is evidence regardless of what the data contained.

FAQ

Does GDPR require a RoPA entry for AI and LLM usage?
If your AI workflow processes personal data — support tickets, CRM notes, HR documents — it’s a processing activity under GDPR Art. 30 and belongs in your RoPA like any other system. The under-250-employee exemption doesn’t apply to processing that is “not occasional,” which rules out any AI feature running daily.

Are prompts sent to OpenAI a third-country transfer?
If the prompt contains personal data and the provider processes it outside the EU, yes — and your RoPA needs to record the recipient, region, and transfer mechanism (SCCs or an adequacy decision). This is exactly the section most companies cannot fill from scattered logs, and the one Talon derives from per-request data-flow evidence.

Do SMBs need EU AI Act Annex IV documentation?
Formally, Annex IV applies to providers of high-risk AI systems, and most SMBs are deployers with lighter obligations. In practice, enterprise customers push documentation demands down through contracts — you’ll be asked to evidence your usage controls, oversight, and logging in security reviews well before any regulator asks.

Is a generated RoPA legally sufficient?
It’s a supporting record, not a legal filing. Talon assembles the runtime facts (recipients, regions, identifiers observed, redaction status, denials) and flags the declarations only your organisation can make (legal basis, retention, purposes). Your compliance officer reviews and signs off — but starts from evidence instead of archaeology.

Does this help with ISO 27001 and NIS2, or only GDPR?
The same evidence store backs both. Signed per-request records support ISO 27001 logging and monitoring controls (A.8.15), the encrypted secrets vault maps to cryptographic controls (A.8.24), and the policy-denial trail supports incident management — which is also what NIS2 Art. 21 risk-management measures ask for. talon compliance report prints the framework-to-control mappings next to the runtime numbers.

Where does the evidence live?
In your infrastructure. Talon is a single Go binary, self-hosted and open source. Prompts, evidence records, and generated documents never leave your environment.

---

• Repo: github.com/dativo-io/talon — single Go binary, self-hosted, open source

• Runbook: How to export evidence for auditors

• Declarations guide: How to clear DECLARATION MISSING blocks in RoPA exports

• GDPR Article 30 text · EU AI Act implementation timeline

August 2, 2026 is on the calendar whether your RoPA is ready or not. The version of you that gets asked question 47 next quarter will be glad the answer is one command.