The Stress Test: Why We Ran Ten Security Sprints Before the First Customer

The gap nobody likes to enter

There's a sentence thrown around far too casually in the AI world: "it runs on my machine." A demo works, a prototype impresses, a video makes the rounds. And then people act as if the rest is just busywork.

The rest is not busywork. Between "it runs on my machine" and "a company entrusts it with its most confidential data" lies a gap many projects underestimate — and one I deliberately walked into in April 2026, before ZenAI was allowed anywhere near real organisations.

It's the least glamorous phase of our whole development story. It shows up in no demo video. And it may be the most important. This post is the chapter I promised in the history of our lab: the stress test.

Why security isn't a feature for us

I believe the most expensive misconception in enterprise AI is treating security and data protection as a downstream layer — as something you "lay over the top" at the end. Compliance was never a coat of paint for us. It was a gate the product had to pass through first.

The reason is simple: the real scarcity in the AI market isn't compute and isn't talent. It's trust. A system that carries a company's knowledge work sees everything — contracts, finances, personnel, strategy. Whoever adopts something like that isn't buying a feature. They're entering a relationship of trust. And trust comes not from a security badge in the footer, but from architecture you can inspect.

So before the first serious deployment, I ran a connected series of ten hardening sprints, back to back. Not in reaction to an incident, but as a precondition.

The ten sprints

Each sprint closed a concrete class of risk. In overview:

1. Encryption and key rotation. Sensitive fields are encrypted at the field level, with a documented key-rotation procedure. Encryption you can never rotate is only half the job.

2. Tenant isolation at the data layer. Strict access separation per context, anchored directly in the database (row-level security), not just in application logic. One tenant's data must under no circumstances see another's — and the database itself should guarantee that, not just the well-meaning code on top.

3. Network hardening. Defences against server-side request forgery (SSRF) and DNS rebinding — the class of attack that tricks a system into calling internal addresses.

4. AI-specific guardrails. Defences against prompt injection and guardrails on outputs, plus three-tier content moderation. A system with tools and memory needs boundaries a plain chatbot doesn't.

5. Data-subject rights, built in. A consent centre with disclosure (DSAR) and full account deletion. Data-protection rights aren't an email to support; they're a function.

6. Transparency obligations. Labelling of AI-generated output under Article 50 of the EU AI Act, the moment it goes to people — and truncation of IP addresses to GDPR standards. The labelling isn't downstream; it's part of the output pipeline.

7. Payment-path integrity. Securing payment webhooks against double-processing and replay attacks.

8. Traceability. An audit trail and forwarding of security-relevant events to the customer's own systems (SIEM), separated per organisation. If you want trust, you have to be auditable.

9. The attack on ourselves. A dedicated penetration-test pass — deliberately stressing the system from the attacker's perspective, instead of hoping.

10. Permissions in the token. A user's entitlements are carried cryptographically in the session token, rather than looked up on every request — less attack surface, clearer boundaries.

Behind this list sit roughly three hundred additional automated tests. Security you don't continuously re-check decays with the next commit.

What it costs — and why it's worth it

These weeks produced not a single visible feature. No user saw a new button afterwards. From a product perspective, it's expensive, invisible work.

And still I'd do it the same way every time. Because at the end came a cross-sprint review — and it actually found one more gap (a missing access rule on a single table), which was closed immediately. That's exactly the point: the goal isn't "zero flaws," it's a process that finds and closes flaws before anyone else does. An honest security promise isn't "nothing can happen to us." It's "we look systematically, and we fix what we find."

On top of that sits the architectural decision that makes all of this meaningful in the first place: data sovereignty. ZenAI can run entirely on your own infrastructure, with no data flowing out — fully local on request. In that picture, GDPR and the EU AI Act aren't a burden you carry; they're a shape you build in.

Trust is the real scarcity

I worked in organisations for a long time and watched AI initiatives fail. Rarely on the technology. Often on a quiet, justified distrust: "where does our data actually end up?"

That question deserves a better answer than a brochure. It deserves an architecture you can open up and inspect. The stress test was our way of giving that answer before anyone had to ask. It was the phase in which an impressive prototype became a system you can actually entrust with something.

This is a chapter of our development story. The next post in the series is about how we deal with AI in principle — where we leave the last word to the human, and why. How we introduce AI into a company in the first place is covered in from the first process to an operating system.