Security & Data Handling
Written for the person who has to approve this
If someone at your firm forwarded you this link, you are probably the IT, security or risk reviewer. This page exists so you can evaluate what we do without booking a call or sitting through a demo.
Engineering firms told us the same thing over and over during discovery: the technology was never the blocker, the approval was. So we design for your approval process from the first week of an engagement.
How we handle your data
Deployed where you say
Your cloud tenancy, your own infrastructure, or a dedicated environment scoped to your firm. Your security team picks the deployment model during Discovery, before anything is built. It is not a constraint we hand you afterwards.
Your data does not train anything
Project material is not used to train or fine-tune models, and it is not pooled across clients. What belongs to your firm and your clients stays scoped to your deployment.
Data residency is a requirement, not a preference
Firms working on government, healthcare, defence and regulated infrastructure told us residency is a hard gate. Where your contracts or policies require data to remain in a specific jurisdiction, that becomes a documented constraint on the architecture.
Access follows your rules
Role-based access aligned to how your firm already separates project teams, disciplines and clients. Where you need integration with your existing identity provider, that is scoped in Discovery.
Everything is written down before it is built
Every engagement produces a data governance, security and usage plan and an integration and dependency checklist as Discovery deliverables. Your team approves them in writing before development starts.
Auditable by design
Systems record what was generated, from which source, reviewed by whom and when. If a deliverable is challenged later, the record exists.
Review questions
The questions we get asked
Does our project data leave our environment?
That depends on the deployment model you choose during Discovery. We support deployment into your own cloud tenancy or infrastructure so project data stays inside your boundary. Where a component calls an external model provider, that path is written into the data governance plan explicitly: what is sent, what is retained, and what the alternatives are. Your team approves a known architecture, not a black box.
Is our data used to train AI models?
No. Your project material is not used to train or fine-tune models, and it is not pooled with other clients’ data. Where we build on third-party model providers, we configure the integration so that submitted content is not retained for training by that provider.
Can this run entirely on our own infrastructure?
Yes, and several firms have told us it is the only arrangement they can approve. Self-hosted and dedicated-environment deployments are a supported model. The trade-offs are real, so we scope them in Discovery rather than gloss over them: infrastructure cost, update cadence, and what your team takes on operationally.
What about client confidentiality and contractual obligations?
Engineering firms hold project material under client confidentiality terms, and in many cases past reports are client property that cannot be shared externally at all. We treat those obligations as a design constraint. Discovery identifies which material can be used, under what conditions, and what must remain out of scope, and that is recorded before any build.
How do we know the AI output is accurate enough to rely on?
Where an engagement depends on AI performing a specific task, we evaluate it against your real documents and verified human ground truth at a proof-of-concept gate before the build begins. We measure performance, document the limitations in writing, and confirm the acceptance criteria still hold. Everything we build assumes a qualified engineer reviews and signs the output. The system makes that review faster and better evidenced. It never replaces it.
Who owns what you build for us?
On acceptance, your firm owns the delivered platform and its commercial rights: the application codebase, your firm-specific workflows, prompts, architecture, configuration and related documentation developed under the engagement. We retain ownership of our pre-existing background tooling and license it to you as embedded within what we delivered.
What happens to our systems if we stop working with you?
You keep what you own. Because the delivered codebase, configuration and documentation transfer to you on acceptance, the system does not stop being yours if the relationship ends. Hosting, support and ongoing development run under a separate agreement precisely so that continuing with us stays a choice rather than a dependency.
Are you certified against a specific security standard?
We are a small engineering firm and we are not going to claim certifications we do not hold. What we do is work to the standard your security team sets, produce the documentation your review process requires, and put the architecture, data flows and dependencies in front of your reviewers before we build. If your procurement process requires a specific certification, tell us early. It is much better established at the start than discovered at contract stage.
Our IT department has blocked AI tools before. How is this different?
Most general-purpose AI tools ask a firm to make an exception to its own policy. We start from the policy instead. The deployment model, data handling, access control and retention are scoped with your IT team as Discovery deliverables and approved in writing before development. IT is a stakeholder in the design, not an obstacle encountered at rollout.
How is this different from the Microsoft Copilot licence we already have?
General assistants are broad and shallow. They are useful for email and meeting notes, and they are usually blocked at the boundary of actual project data, which is where firms told us the value was. We build systems that run on your templates, your standards and your project material inside the boundary your security team approved, and we evaluate them for accuracy on your documents before you depend on them. Several firms we work with have Copilot deployed and still cannot use it for the work described on this site.
Have a question this does not answer?
Send it to us directly. If your review process needs specific documentation, tell us at the start of the conversation rather than at contract stage. It is much easier to design for.
Also relevant: AI on confidential data and oversight and governance.