The part nobody scopes
The first question is whether it works, and the answer is usually yes. A capable model on a clean example is genuinely impressive, which is why so many pilots get approved.
The second question is who can see what, where the data goes, what happens when the model is confidently wrong, and who is accountable when it is. That question does not arrive from the enthusiastic stakeholder who commissioned the pilot. It arrives from legal, from a trustee, from a technical reviewer, or from the person whose data it is, and it arrives after the money is spent.
We work in the reverse order. The constraints come first and the architecture is built to satisfy them, because a design that cannot answer the second question is not an unfinished project. It is a project that will be stopped.
Four stages, each with a fixed scope and something you keep at the end of it. You can stop after any one of them, and the deliverable is still yours.
We interview the people who do the work, read the systems you already run, and put your candidate use cases in order of value against difficulty. The output is a written assessment: what is worth building, what is not, what it would cost, what it would touch, and where your obligations constrain the design. It includes an explicit list of things we recommend you do not build, which is usually the section that saves the most money.
The chosen use case gets a real architecture before it gets code: the data flow diagram, the access model, what is redacted and where, what the failure behaviour is, and how you will know whether it is working. We agree an evaluation set at this point, meaning the specific cases the system must get right, so that acceptance is a measurement rather than an impression.
Built against the evaluation set agreed in stage two, released in phases rather than as one launch, and instrumented so that every call is attributable. You see working software early and often. Where a phase misses its evaluation bar, we say so and adjust the design rather than shipping it and calling it iteration.
Code, prompts, evaluation sets, data flow documentation, and the written reasoning behind each design decision, in a form your team or a different firm can pick up. We can stay on to run it, but that is a separate decision made after handover rather than a dependency created during the build.
Data protection and guardrails
These are not principles we intend to adopt. Each one is implemented and running in the platform we build and operate ourselves, and each is a default we carry into work we do for you. Your technical reviewer is welcome to interrogate any of them.
AI features ship disabled. Nothing reaches a model until an administrator in your organisation explicitly enables them, and switching them back off is a single setting, not a support ticket.
Viewing an AI result and invoking a model are separate permissions, granted by role. A field user or an external contact holding a login does not inherit the ability to run queries against your data.
Email addresses, phone numbers, card numbers and national insurance or social security identifiers are redacted from text before any of it is sent onward. This is pattern matching over known formats. It reduces what leaves rather than guaranteeing nothing personal ever does, which is why it sits behind the permission and consent gates rather than in front of them.
When a model writes a query, that query is treated as hostile. It runs read-only, under a restricted database role that cannot bypass row-level security, scoped by the database itself to the asking user's own organisation, under a hard time limit. No wording in a prompt can widen it, because the prompt is not what is doing the enforcing.
We build on Anthropic's commercial API, whose published terms state that retained data is never used for model training without express permission, and that prompts and outputs are not retained by default. Read the policy at the source rather than taking ours for it.
Model, duration, token count, cost and a trace identifier are recorded for each request, tied to the organisation that made it. When somebody asks what the AI did in March, that is a query, not an investigation.
Controls described here are implemented in the ClickWerxs platform and are the defaults we carry into work we build for you. Where your own obligations go further, whether that is a data processing agreement, a named retention period, residency in a particular jurisdiction or a zero-retention arrangement with the model provider, those are scoped before a line of code is written rather than retrofitted afterwards.
Not a maturity score and not a slide deck of industry trends. A specific read of your systems, your constraints, and the work your people are actually doing.
Every candidate use case scored on value, difficulty, and risk, then ranked. Most organisations arrive with one idea and leave with a different one that was cheaper, safer, and worth more.
Where the data lives now, what would move, which processors would touch it, and what is retained at each hop. Written down in a form you can hand to a reviewer without translating it first.
Your regulatory position, contractual commitments to third parties, and any restrictions on where processing may happen, captured as design constraints at the start rather than discovered as blockers later.
A good share of AI projects are really undocumented processes. We map the workflow first, because automating a broken process reliably produces a broken process that now runs faster.
The evaluation set: the specific cases the system must handle correctly, agreed before anything is built. Without one, nobody can say whether a deployment succeeded, and everybody defaults to whether it felt impressive.
Which of your people will own this, what they need to know, and what it takes to keep running. A system that only the vendor understands is a liability, whatever it does in the demo.
Whether or not you continue with us. The assessment is a deliverable, not a sales document with a scope of work attached to the back of it.
Where we are not the right firm
We would rather lose the work early than be the wrong choice expensively. If any of these describe your situation, say so on the first call and we will tell you plainly.
You need a global firm's name on the report
Sometimes the deliverable genuinely is institutional cover for a decision already made. That is a real requirement and we are not it.
You need model research rather than applied engineering
We build systems on top of frontier models. We do not train foundation models, and organisations needing original ML research should hire researchers.
You need dozens of consultants next month
We are deliberately small. That is why the person who scoped your work is the person who builds it, and also why we cannot staff a programme at scale.
The decision has already been made and you want it validated
Our assessments regularly recommend against building the thing that was requested. If that outcome would be unwelcome, the engagement will be unwelcome too.
Data handling, ownership, accountability, and scope. Answered here rather than deferred to a security questionnaire later.
A fixed-price piece of work with a written deliverable you keep, whatever you decide afterwards. We quote it against your scope rather than publishing a rate. Tell us what you are looking at and we will come back with a figure and a duration. If you would rather see the engineering first, the implementation work and the AI running in our own platform are both worth a look. If the problem is that nobody can find you in the first place, AI SEO is the other conversation.