For teams taking an AI system into production
FatFish combines AI assurance with senior engineering to help your team identify control gaps, implement the changes you agree, and prepare evidence for security, governance and deployment decisions. Your approvers keep that decision. This is not regulatory approval or certification.
Built for
Technical owners who need a boundary and a roadmap their engineers can use
Security, governance and operations who need findings tied to evidence before they decide
Product leads balancing a working pilot with a deployment decision
Trusted by teams in health, financial services and the charity sector
Fat Fish Digital have been outstanding partners — their AI integration has transformed SOPHIA into a smarter, faster tool for managing governance at scale.
The people
David Lane holds the scoping call and leads the assessment. David Caswell chairs the company. Owais Nizam reviews the architecture and leads the engineering changes you agree.
Co-Founder & CEO
Twenty years building and running software in regulated settings, most recently digital health, where a system has to be safe and auditable. He founded FatFish in 2013. More than 100 products shipped, used by more than a million people. First-class degree in Computer Science and AI, University of Sussex. AWS Certified AI Practitioner.
Co-Founder & Chairman
Marketplace and health-tech specialist, advisor and investor. He co-founded Rated People, a UK home-improvement marketplace, and chairs Welldoing.org and Carradale Futures, the company behind SOPHIA.
Tech Lead
Software architect and engineer. On this engagement he reviews the architecture and leads the changes you agree, alongside your engineers, in the stack you already run.
Security, governance and operational owners need evidence that is not yet in one place. The gap is between a working system and a decision other people can stand behind.
Legal duties, standards, sector guidance and your own governance rules are different. Mixing them does not tell approvers what applies to this system.
Your engineers can build the system. What is often missing is the control design, the evidence, and a roadmap both groups can use.
Start here
A paid review of one AI-enabled system, inside a boundary agreed before work starts. It identifies control gaps, the evidence approvers are likely to ask for, and the changes your team would need to make. It uses FatFish’s Responsible by Design approach to keep AI behaviour explainable and evidenced. The assessment does not itself constitute regulatory approval or certification.
The system boundary and the fixed fee are agreed before work begins. A standard fee, duration and start date are not published.
After the walkthrough, the roadmap is yours. Your team can use it, or you can ask FatFish to implement the changes you agree, alongside your engineers. Further work is scoped separately. You do not have to continue.
What you receive
The scope names the applications, models, integrations and environments included. Anything outside that boundary is out of scope.
A technical owner for the system, and the security, governance or operational stakeholders who will use the findings. Those people are named before work starts.
Documents, repositories, configuration and existing evidence for the system in scope. Do not send passwords, credentials or confidential material through the enquiry form.
The scope says which topics are reviewed from documents and configuration you already hold, and which are checked directly in the agreed environments. That is not a test of every control.
Each finding is tied to the evidence it came from and ordered by how it affects a deployment decision. Effort ranges on the roadmap are indicative, with the assumptions stated. They are not a fixed price for remediation.
We walk the technical owner and the stakeholders named in the scope through the findings and the evidence. Your approvers still decide whether the system is ready.
Legal obligations depend on the organisation, the activity and its role. UK GDPR is often relevant where personal data is processed. The EU AI Act can apply to providers, deployers and some other roles, including organisations outside the EU in defined cases, such as placing a system on the EU market or the system’s output being used in the EU. It is not one duty that applies in the same way to every UK organisation. Standards are separate: ISO/IEC 42001 is a standard for an organisation’s AI management system, and ISO/IEC 27001 is an information-security management standard. Reviewing one application does not assess or certify that management system. Sector guidance, such as the NHS DSPT, applies to organisations in that sector and is not a substitute for the law or for a management-system standard. Internal governance and customer assurance requirements, including security reviews, contracts and accessibility expectations, can also decide whether a system is deployed. We identify what appears relevant. We do not give legal advice.
Assurance-to-Deployment
Assurance-to-Deployment is how FatFish continues after the assessment, when you ask us to. We work in your stack, with your engineers. Responsible by Design is the methodology we use so AI behaviour can be explained and evidenced. Your approvers keep the authority to deploy.
Agree the system boundary, the requirements that apply inside it, and the evidence you already have. The assessment records the gaps.
Define who is responsible, where a person must oversee or escalate a decision, and the technical controls in the architecture. Where they are in scope, that includes access, logging, monitoring and how model or configuration changes are handled.
FatFish engineers implement the changes you agree, in the existing stack, alongside your engineers. We do not take the system away from your team.
Assemble the evidence behind the controls and walk your decision-makers through what it shows and what it does not. They decide whether the system is ready. You keep the map, the roadmap, the control descriptions and the evidence pack.
Illustrative example
This is an illustration, not a completed client engagement.
A system drafts a procedure from source documents. A person has to approve the draft before it is used. The intended use is drafting, not unattended publication. The people affected are the author and the approver. One failure scenario is a draft that drops a required step and is approved because the omission is hard to see.
A review would look for the documents the model can use, what is sent outside the organisation’s own environment, who may approve, what is logged when a draft or the model changes, and how a bad draft is withdrawn. Findings would say which of those are in place and which are missing, each tied to evidence. They would not approve the system for production.
Where the scope includes them, FatFish looks at intended use and failure scenarios, model behaviour against that use, data handling, human oversight and escalation, monitoring and change control, and architecture-level security. The published SOPHIA work is a separate build. This example only shows how controls and evidence fit together.
Selected work
David Lane, Co-Founder and CEO, leads the consulting engagement and the assessment.
The system boundary and the fee are agreed before work begins. We do not publish a standard price.
Each finding points to the document, configuration or direct check it came from.
Agreed changes are made with your engineers, in the systems you already run. Published FatFish work includes Azure and AWS.
You keep the system map, the roadmap, the control descriptions and the evidence pack.
The roadmap is written so your own team can act on it if you do not commission further work.
An AI-enabled system whose failure or delay has operational consequences. An internal technical owner. Identifiable security, governance or operational stakeholders. Budget and the authority to act on the findings. Organisations in this position are often established, including universities, NHS bodies and charities as well as companies. Revenue above £3m and teams of more than 50 people are typical. They are not eligibility rules.
A policy document with no change to the system, a team to replace your engineers, or an assessment that itself certifies the organisation or approves deployment.
No. We work in your stack, with your engineers. The handover is the map, the roadmap, the control descriptions and the evidence pack, so your team can maintain them.
No. It reviews one system inside an agreed boundary and gives your approvers evidence and a roadmap. It is not regulatory approval, and it is not certification of the organisation. ISO/IEC 42001 is a standard for an AI management system across an organisation. Reviewing one application does not assess or certify that system of management.
We separate legal obligations, standards, sector guidance, and internal or customer requirements. Which of those matter depends on your role, your activity and the system. UK GDPR is often relevant where personal data is processed. The EU AI Act can be relevant to providers, deployers and some other roles, including some organisations outside the EU, but it does not apply in the same way to every UK organisation. We do not give legal advice.
We work in the stack the system already runs on. Published FatFish work includes Azure, including the SOPHIA AI module, and AWS. If your platform is different, say so on the scoping call and we will tell you whether we can work in it.
You own the roadmap. Use it with your own team, or ask us to implement the changes you agree. Further work is scoped separately. There is no obligation to continue.
No. It is a request. David Lane, Co-Founder and CEO, holds the scoping conversation: the system, what is blocking a deployment decision, who owns it technically, who needs to be satisfied, and the likely priorities for an assessment. We reply to arrange a time. We do not publish a response time.
The assessment can look at one system and the evidence a customer is asking for. This page is written for organisations that already have a technical team and need to move their own system through assurance. It is not a programme for winning a first enterprise client.
Timing is agreed with the scope. We do not publish a standard lead time.
Tell us about the system, who owns it technically, and who needs to be satisfied before deployment. David Lane, Co-Founder and CEO, will discuss the system and the assessment priorities that are likely to matter. If there is a fit, the next step is to agree the boundary and a fixed fee before any assessment starts. Sending this form does not confirm an appointment, and we do not publish a response time.
