Eidetic

Robin Miklinski Independent AI & software engineer · London

Before you launch an AI product, someone needs to prove it won’t fail. That’s what I do.

I build AI products and the controls that make them safe to release: evaluation, access boundaries, observability and human oversight. Then the evidence that shows what the system may do, when it must stop and whether its output can be relied on.

Discuss a system → See the evidence →

01 / What I do

AI products rarely fail at the model boundary alone. They fail because context is incomplete, permissions are too broad, outputs cannot be explained, or a release decision rests on a convincing demonstration rather than repeatable evidence.

  1. 01 Build dependable AI systems

    • evaluation
    • permissions
    • tenant isolation
    • failure behaviour
    • human control
    • escalation
    • agents
    • retrieval
    I design and build AI-enabled software with the controls in place from the start. The model is one component in a complete product.

  2. 02 Evaluate and harden existing products

    • acceptance criteria
    • repeatable evaluations
    • adversarial tests
    • model and prompt change management
    • release evidence
    I turn broad expectations into measurable criteria. The result shows what the system can do, where it breaks and what remains uncertain, in a form a board or a customer’s risk team can act on.

  3. 03 Find where confidence breaks down

    • observability
    • security
    • cost
    • latency
    • accuracy against autonomy
    I investigate failures across models, prompts, tools, data and the software around them. That includes the commercial questions: what it costs to run at the cadence you need, and how much autonomy its accuracy supports.

Output is abundant. Confidence is not.

Models can produce code, analysis and plausible answers. The difficult work is deciding whether an output is correct, whether the system has enough context, what it is permitted to do and who remains accountable when it fails. That is the layer I engineer.

  1. Understand how the work gets done today
  2. Find the parts that could be simpler
  3. Remove what isn’t earning its place
  4. Build the smallest complete system
02 / The story

A launch decision with no evidence behind it.

I took responsibility for quality and release assurance on the first customer-facing AI product at Reward Gateway, the employee-benefits platform Edenred acquired for £1.15bn. The application had already been built. The evaluation infrastructure had not. It was a retrieval-based assistant serving many enterprise customers from one system, where a failure of isolation is not a bug in one account but a disclosure across several. There was no defensible basis for deciding whether it was ready to launch.

Because the model’s wording varied between runs, conventional exact-output checks were insufficient. The same prompt can return three different answers and all of them be acceptable. I replaced pass/fail equality with semantic assertions, classifier-based validation and sampling across repeated runs, so the suite could judge whether a response completed the task and stayed inside the system’s rules. The adversarial half covered direct and indirect prompt injection, jailbreaks, tenant data isolation, personal data leakage, authentication flows and retrieval scope.

The results exposed gaps that mattered before launch. I also told the go/no-go panel what the suite could not do: without a labelled dataset there was no way to measure answer accuracy at scale. It was recorded as residual risk, and the panel launched knowing exactly what the evidence did not cover.

The suite became the release gate for later AI work and set the platform’s wider AI testing approach: AI-assisted test generation, and risk-based test selection driven by what a code change touched.

03 / Evidence

Selected evidence.

Three records, each labelled by what backs it. The complete register lists the rest under the same labels.

Agent infrastructure 2026

An agent environment that denies risk by default

My agent environment denies high-risk operations by default and checks proposed changes before they reach external systems. Agents extend what one person can do; their authority stays explicit.

Control Private working system
Reward Gateway 2024–2026

Conformance evidence enterprise buyers accepted

At Reward Gateway I ran a WCAG 2.2 AA and VPAT conformance programme across web, iOS and Android, producing the audit evidence enterprise customers required before they would buy. The same discipline applies to AI: someone outside the company has to be able to check the claim.

Assurance Employment history
ZAPClient Python

Security scanning in the delivery pipeline, since 2015

I began integrating automated security scanning into continuous delivery in 2015 and later published an OWASP ZAP client. The tools have changed; the principle has not: test boundaries before release.

Platform / Security View Repository →

Open the complete evidence register →

04 / About

Robin Miklinski

Background

I began in defence data systems, where a change had to be traced to its reason and a boundary had to hold against an assumed attacker. Since then I have worked across retail, collaboration software and global SaaS, from product decisions and architecture through to implementation, evaluation and production reliability.

I write Python, JavaScript, TypeScript and C#. I can build both the product and the evidence needed to judge it, which matters most when failure can be fluent, plausible and wrong.

Outside work

I produce electronic music and DJ as Eidetic. It is a different medium, but it draws on similar habits: close listening, deliberate iteration and knowing which details matter.

05 / Contact

Tell me what the system must do, and what must never happen.