Somebody asks where the customer telephone numbers are held. In most companies the honest answer is a fortnight of interviews and a spreadsheet that is out of date before it is finished. The knowledge exists, but it is spread across eleven people, six repositories and a schema, and the map goes stale again with the next release.
EVIDENT (opens in a new tab) is the product we built at Ximplicity to change that answer: it reads your databases, your code and the APIs you expose, and tells you where personal data actually lives — in an afternoon, not a quarter.
EVIDENT rests on a very simple idea:
You cannot trust an analysis system that tells you one thing on Monday and something different on Tuesday. That is why EVIDENT does not rely on what an AI happens to interpret, but on reliable, predictable rules that always say the same thing in front of the same evidence — and that, when they cannot find it, do not lie.
A lot of tools now promise to find your personal data, and almost all of them promise it the same way: with AI. We made a different bet, and the rest of this article is about why.
The shortcut everybody takes
There are two easy ways to build a personal-data scanner today.
The first is a heuristic search: match column names against a list — email,
phone, dni — and call the matches personal data. The second is newer and
sounds smarter: index the schema, the code or the API descriptions, hand them to
a language model and ask it which fields are personal data.
Both produce an answer quickly. Neither produces something you can defend. A
name match does not know that a column called orientation in a table of solar
panels has nothing to do with a person. A model's answer cannot be reproduced
next month, cannot tell you which version of its reasoning produced it, and
cannot say what it did not look at. When a data protection officer, an auditor
or a regulator asks why, "the model said so" is not a reason.
Extensions that go looking for evidence
In EVIDENT the work is done by extensions (opens in a new tab): named, versioned pieces of the platform, each of which knows how to read one kind of system and carries the rules and patterns for finding evidence in it.
Each extension is a thing with a name and a version of its own. That sounds like an implementation detail, and it is the heart of the product. It means a finding can say exactly which reader and which rule version produced it. It means a report from six months ago can be read in the terms that applied six months ago. And it means the product grows by adding extensions — a new engine, a new framework, a new kind of interface — without changing what the core already asserts.
Many languages, many engines, one model
Personal data does not live in one place, and it is not described in one language. Finding it means understanding every layer it passes through — and that, more than any algorithm, is where the expertise behind EVIDENT shows.
SQL, across engines. EVIDENT reads PostgreSQL, SQL Server, MySQL, MariaDB, Oracle and SQLite through their own catalogues (opens in a new tab): tables, columns, types, constraints, foreign keys and comments. Structure, not rows. Six engines do not agree on what a type is called or how an object is identified, so behind the readers sits an engine-neutral introspection contract and a canonical type system — the same column means the same thing whichever engine it came from.
Code, across languages. A schema tells half the story; the code that maps onto it tells the rest. EVIDENT reads the ORMs teams actually use, in the languages they actually write: C# with Entity Framework Core, TypeScript with Prisma and TypeORM, Node.js with Sequelize, Python with SQLAlchemy and the Django ORM, Java with JPA and Hibernate. They all feed one code model, so a field is understood through the property, the entity and the decorator that use it — not only through its column name.
APIs. What a system exposes to others matters as much as what it stores. EVIDENT reads OpenAPI and GraphQL descriptions to see which operations return personal data, which require a caller to prove who it is, and which data a caller can reach without any operation returning it directly.
Logs. Beyond the relational world, EVIDENT looks at what application code writes to its own logs and events — entities handed whole to a logger, fields holding personal data, credentials. A field in a log is kept for as long as the log is, and cannot be erased on request.
And beyond relational. Today's release reads relational databases, code, APIs and logs. The extension architecture was designed from the start so that non-relational sources — document databases, search engines, caches, message brokers, analytical warehouses — become new readers rather than a rewrite. That is exactly where it is heading.
A pattern is a candidate, never a conclusion
The rules inside those extensions are deterministic and readable (opens in a new tab): the same systems and the same rule version give the same result, every time. But a rule matching a pattern is only where the work starts.
A match is a candidate. Context decides: the meaning of the table, the
neighbouring fields, the foreign keys, the declared types, the comments, the code
that maps the column, and the vocabulary of the organisation itself. A
correlation engine looks at combinations of fields, not at each one in
isolation, because two harmless columns together can identify a person. Where
the context says nothing at all, a critical conclusion is proposed for review
rather than asserted — silence is not agreement. And where a word has no second
meaning, as with a column called BiometricTemplate, it needs no corroboration.
That is the difference between finding evidence and guessing from names, and it is the difference between a useful tool and a noisy one.
Evidence before inference
The values behind EVIDENT are the ones you will find on every page of its website, and they are not decoration. They are design constraints.
Every statement says what kind of statement it is. EVIDENT keeps apart what was observed in a system, what the organisation declared, what a controlled document says, and what was inferred from other evidence — with a confidence and a rationale. Each finding carries its own chain, so a reader can follow exactly how a column came to be labelled as health data or a criminal record.
UNKNOWN is a result. Where the evidence cannot support a conclusion, EVIDENT says so, and names the evidence it would need to decide. It does not guess, and it does not average a missing answer into a percentage. What could not be observed is reported as such, never counted as a success.
A legal category is not a sensitivity level. What the GDPR calls the data — personal data, a special category under Article 9, conviction data under Article 10 — is kept separate from EVIDENT's own ordering of what to review first, so the product never presents its own scale as if the regulation had defined it.
No compliance score. EVIDENT reports evidence and gaps. It does not certify legal compliance (opens in a new tab), and it says so on every page. A score looks like progress and hides the four places that would actually have mattered.
A person decides what the rules cannot
Rules settle most of a system, not all of it. What they cannot settle goes to a review queue and to a person (opens in a new tab). Their decision persists across runs; a correction is recorded with who made it and when, and reopening a decision is itself recorded as a decision. That trail is the part an auditor actually reads.
Because systems change, EVIDENT is built to be run again, not once. A new analysis keeps every confirmed decision, flags what has gone stale and lets you compare two assessments, so you can tell what was genuinely fixed from what still stands only because nothing about it changed.
So where is the AI?
Where it is useful, and nowhere else. AI in EVIDENT explains evidence and drafts text for a reader, clearly marked as such. It never creates a fact, never overrides a rule and never turns a low confidence into a high one. Nothing is sent to a model unless you switch that on and say what it may send.
This is not scepticism about AI — we build AI systems for a living. It is a judgement about where it belongs. When the question is whether a column holds special-category data, the answer has to be reproducible, versioned and explainable to someone who does not trust you. Rules and patterns, carried by extensions and checked against context, can give that answer. A model can help a person read it.
Security and data protection by design
A tool that inspects where personal data lives has to be held to a higher standard than the systems it inspects. In EVIDENT that standard is not a checklist added at the end; it is in the architecture.
- It never touches what it analyses. Repositories and databases are read through read-only, least-privilege connections (opens in a new tab), and application code is read, never executed.
- Metadata first. By default EVIDENT reads structure only. Profiling and sampling of real values are each an explicit opt-in, per project.
- Secrets stay secret. Connection secrets are never written to a log. Credentials are encrypted at rest and bound to the connection they belong to, and secrets found in code are redacted before they are stored and again on the way out — so the platform can report that a secret exists without ever repeating it.
- Access is decided by role, through a single authorisation model, and the token a request carries can narrow its permissions but never widen them.
- Everything leaves a trail. Scans, reviews, exports, policy changes and administrative actions are audited, and the audit trail is kept separate from telemetry.
- Your infrastructure, if you want it. EVIDENT runs hosted or on your own hardware, including air-gapped environments (opens in a new tab), with a licence verified offline.
Well-made code, because the product is the evidence
A product that asks to be trusted with evidence has to be able to show its own. That is why the way EVIDENT is built matters as much as what it does.
Every significant design decision is written down as an architecture decision record (opens in a new tab) — close to sixty of them so far, and they ship with the source. Their titles read like the product's principles, because they are: a name is a candidate, not a conclusion; evidence is the record and a report is a projection; broken references are reported, not repaired; a displayed state must be reconstructible; a package is checkable without us.
The engineering behind it is the same we apply for our clients: a TypeScript codebase with a NestJS backend and an Angular client, a single write path through which every change to the platform's state has to pass, a contract per plugin instead of special cases, client tests that run in a real browser, and quality gates in SonarQube on both sides. None of it is visible in a screenshot, and all of it is the reason the screenshots can be trusted.
The result shows up as documents people need (opens in a new tab) rather than a dashboard to admire: the GDPR Article 30 record of processing activities, a risk register, coverage and gaps, logging exposure, the security of the interoperability layer and referential integrity — exported as HTML, Markdown, CSV or XLSX.
The first releases, and what is coming
EVIDENT is in its first releases, and we say so without embarrassment: every capability on its website is labelled Available, Preview or Planned, and nothing is described as finished before it is.
What comes next is considerably more powerful. A portable evidence package (opens in a new tab) that
anyone can verify with sha256sum, without us, and verification of remediations
are already in preview. Framework adapters (opens in a new tab) for GDPR, ISO 27001, ISO
27701 and the EU AI Act, an evident command line, governance gates inside a
CI pipeline (opens in a new tab), and a local agent for sources that cannot be reached from outside
are on their way — along with new readers for the sources that do not speak SQL.
We expect to surprise you very soon, and when we do, the product site will show
it in the same plain terms: available, preview or planned.
Honesty, transparency and evidence
Those three words are not a slogan for EVIDENT; they are the specification. Honesty, in saying what the product does not do and what it could not observe. Transparency, in showing the rule, the version, the reader and the person behind every conclusion. And evidence, as the only thing a conclusion is allowed to rest on. Trust is built on the three together, and that holds for the product as much as for the team that builds it.
The quickest way to judge whether evidence beats guessing is to look at it. There is a 20-minute demo (opens in a new tab) on a fictional shop — no account, no card, a fresh copy for each visitor, deleted when the session ends — and a 30-day free trial (opens in a new tab) with every capability available today, which ends by itself. If you would rather talk it through, we are here (opens in a new tab).