Is Your Business Ready for the EU's Lawyers?

This site uses cookies to understand how visitors find us.<br>You can accept or decline non-essential cookies.

Decline<br>Accept

Menu

manifesto<br>docs<br>blog<br>roadmap<br>worker registry

GitHub

Discord

install.sh

I am not a lawyer and this is not legal advice. What I am is the person who updates the software stacks when the lawyers say we need to comply with a new regulation, and as such I want to share my well informed opinion on how most software companies will deal with the EU AI Act when it’s in full effect: terribly, and with countless billable hours reconciling logs when enforcement comes knocking. This is because present day logging infrastructure, even if “end-to-end,” is not designed for the court room, it’s designed to find outages and bugs. It won’t survive contact with the coming requirements.

You may have heard that on August 2nd the EU enacted Article 50 of its AI Act, which is related to disclosure. You need to tell users when they’re talking to an AI chatbot, viewing AI generated content, etc. Simple enough, and many businesses are already doing this. Far fewer businesses are prepared for what’s coming next: Article 12, 19, 26, and 86. These articles cover:

Article 12: Recording what your AI agents are doing across any part of your business that interacts with customers and their data.

Article 86: The right of any customer to ask about many kinds of activities and to have you explain why your AI agent took an action, and exactly what it did.

Article 19 & 26: Retention requirements that these logs be kept.

If you grabbed a software provider randomly out of a hat you’d find that most of them would be able to meet requirement 3 relatively easily by expanding their log retention period, and may already meet it today. The others, not so much.

Bundles of gzipped logs stored on offsite servers and tape are not going to be easy to dig through when a customer asks why an AI agent denied their employment application. Only compounded by the fact that your API gateway, AI agent, and database logs all represent separate sets of logs and traces. Logs and traces that likely disagree with each other. Decision criteria that may be mismatched across different versions of the software that produced them.

Start digging through logs intended to find outages or bugs and you’ll quickly find no single throughline for why or even how a decision was made. This is the difference between your current logging process and what the EU AI Act wants, and it’s one of several traps that many companies are going to walk right into.

The traps are:

Logging agent conversations is enough

We’re not in one of those industries and won’t be affected

Our stack already covers this

It’s delayed, we’ll build it closer to the deadline

What modern observability looks like

Before we get to the traps I want to illustrate a core and fundamental property of iii, which is not just something I’m passionate about but clearly illustrates the issue that present day systems have with the EU AI Act.

Here’s the command you need to run to add end-to-end observability to iii: iii worker add iii-observability, or ask our agentic harness to “add observability” with a two word prompt.

Here’s the code you need to add and maintain on each of your services to reconcile traces across your production environment and produce the end-to-end traces you’re going to need to comply with EU regulations:

// It's empty, you don't need any code.<br>Here’s the code you need to add when you incorporate a new AI agent into your existing iii system:

// It's the same. Zero.<br>There is no code to add, there is no platform to change, it’s just a configuration file pointed at your logging platform, and you might also need to bump your OTel logger’s retention period. iii exports to any OTel logging platform. No other system that I’m aware of has this capability to truly map decisions and actions end-to-end.

The configuration is uncomplicated too, so much so it’s obvious what it does without even looking at our docs:

- name: iii-observability<br>config:<br>enabled: true<br>exporter: both # memory for the live console, otlp for durable retention<br>endpoint: http://otel-collector.internal:4317<br>metrics_enabled: true<br>logs_enabled: true<br>sampling_ratio: 1.0 # you do not sample the thing a regulator will ask about<br>In iii a trace that starts at a browser click, passes through an agent, hits a Python scoring worker, writes to state, and renders back in the browser is one trace, because there is one engine mediating all of it.

In a conventional stack every hop is a separate integration: the gateway, the agent framework, the scoring service, the database layer. Each one needs instrumentation code written, tested, and maintained, and each one is a place where the trace can break silently. You end up needing to accept some unknown level of fragility in the records you’ll be handing to a regulator.

As mentioned earlier, existing observability systems...