How we use AI, honestly
Which parts of our work use a model, which parts never do, who signs what you receive, and why your code is never used to train anything.
Updated 7 September 2026
The short version
We use automated scanners and AI-assisted tools for parts of our work.
That is not a boast, it is how the firm runs. Two engineers can publish these prices, and work the way we do — you in your own time, us in ours — only because the repetitive half is done by software. The half that needs judgement is not, and this page is the line between them.
The facts never come from a model. What is inside your software, which weaknesses affect it, which group your product falls into, which dates apply to you — all of that comes from tools and from rules we publish. Models help us draft and sort. An engineer of ours reads and signs everything you receive, and their name is on it.
Your code is never used to train any model. If your own policy rules out models altogether, say so: we do the same work by hand, it takes longer, and we write that into the contract.
Facts from tools, words from the model
Software works out the answers that matter, and no model is asked for any of them. That covers whether the law reaches you, which group your product is in, who checks your work, how long you support the product, your deadlines, how serious a finding is, and every price.
Our own rules decide those. Underneath them, well-known open-source scanners read your code and your components: syft, grype, osv-scanner, semgrep, gitleaks, trivy and Scorecard. They run on our own machine, not on a server, so your code is never copied to one. The rules are the same ones that run the scope check on this site, and they are versioned: every document records which version produced it.
Regulatory numbers come from a single facts file, each with a link to its source. No model is ever asked what the law says.
Where a model is used, and what it may never do
Matching findings to our checklist
- What the model does
- Suggests which item a finding relates to, and why
- What it may never do
- Change how serious a finding is, or invent an item
First draft of a threat model
- What the model does
- Writes a first narrative from your notes, component list and findings
- What it may never do
- Claim something is handled without evidence
Filling in a document
- What the model does
- Fills our templates from the facts we supply
- What it may never do
- Use anything we did not supply — unknowns are printed as
[TO CONFIRM]
Explaining a match during an engagement
- What the model does
- Summarises it, guesses whether the risky code can be reached, drafts the wording you would use
- What it may never do
- Decide that a weakness is actively being exploited — that stays your call
Answering a question in the portal
- What the model does
- Answers from our knowledge base, with citations
- What it may never do
- Give legal advice, or answer with no source
Research before we contact you
- What the model does
- Reads a company's public pages to judge whether we can help
- What it may never do
- Record any individual's name, role or contact details
Nothing else calls a model. The scope check, the price calculator, the deadline clocks, the vulnerability feeds, the scanners, the evidence store and the audit log contain no model calls at all.
A person signs everything
Every document you receive carries a sign-off: a named engineer, a timestamp, the version and what changed since the last one. There is no route through our platform that releases a document to you without one.
There is no exception to that, and there is no machine-written message either. We do not watch anybody's product and we send nobody an alert, so nothing leaves this firm unread. The monitoring we help you set up runs in an account you own and alerts your own people; the runbook and the draft wording that go with it are written and signed like every other document you get from us.
Work goes to a reviewer automatically whenever the tooling is unsure, on anything with a sign of active attack, and on every generated document whatever its confidence. The reviewer accepts, edits or rejects with a reason. What you read is what the reviewer wrote, never what the model wrote.
Your code is not training data
We do not use your source code, component lists, configuration, documentation or scan results to train, tune or test any model, ours or a provider's. That is in your contract, not only on this page.
We send an extract to a model provider only where that provider's terms say inputs and outputs are not used for training, and only in an EU region. Our list of sub-processors is published and names the term for each one; you get 30 days' notice of any change.
What we send is the smallest piece the step needs — one finding, a component name and version, the facts for one section — never a whole repository.
What is actually switched on today
We would rather tell you the state of things than a marketing sentence.
Today the platform runs a stand-in that produces structured output from the inputs, sends nothing anywhere, and makes demos and tests repeatable. The provider we have chosen for production is an Anthropic model on AWS Bedrock in an EU region. That connection exists but is switched off, and it stays off until the region, the model and the no-training term are recorded and a founder turns it on for a named customer. A customer whose policy says "no model on our material" keeps that setting, and the work is done by hand.
Every call is recorded
For each AI-assisted step we store the task, the provider and model, the versions used, timings, token counts, cost, and whether it went to a reviewer and why. We do not keep the prompt or the answer as text in that record, and the working log that does keep a trace is cleaned first: email addresses, keys and tokens removed, long text replaced by a checksum. Ask us for the record behind any document we gave you; your data export includes it.
Where this sits under the AI Act
We use general-purpose models behind our own gateway to draft text, suggest matches and rank companies for engineers who then review them. Nothing we produce makes an automated decision with legal effect on a person, and what you receive is a document signed by an engineer, not access to a model. The human oversight is what this page describes: named reviewers, sign-off records, and work routed for review. Nothing reaches an authority through us in any circumstances, and nothing reaches you unsigned.
We describe our practice here, not our classification. Where your own assessment needs a legal position on Regulation (EU) 2024/1689, take advice — we do not give it, here or anywhere else.
Questions
Want the detail — thresholds, providers, what is stored? Write to us through the contact page and we will send you the internal record this page is drawn from. If you are already a customer, the same summary is in your portal.