The controls that get an AI system past your own risk review. Private deployment inside your boundary, access control on every retrieval path, evaluation before each release, logging you can still query six months later, and human review wherever a decision carries real consequences.
Trusted By
750+ happy clients, including top Fortune 500 companies
What It Is
Most AI systems that stall never actually fail a review. They never reach one. Nobody wrote down where the data goes, who reviews an output, or what happens when it is wrong, so the build finishes and then sits for a quarter waiting on a document that was never anyone’s job.
This engagement makes that document a deliverable and puts real controls behind it. We inventory what you run, classify it by what it decides, and design controls proportionate to that classification. A summariser and a system influencing an outcome for a person should not carry the same burden. Programmes that ignore that distinction collapse under their own weight within a year.
What you end up with is evidence: controls wired into your pipeline, an evaluation set that gates releases, and documentation in the form your auditors expect.
Four Questions It Answers
Who It Is For
Usually one of these has already happened. It is a shorter and cheaper engagement before the questionnaire lands than after it.
The system works and it still cannot ship, because nobody documented where the data goes, who reviews an output, or what happens when it is wrong. That documentation is one of the things this engagement produces.
Tools bought on departmental cards, prompts carrying customer data, and no inventory anywhere. That is why the engagement opens with a search before it opens with a policy.
A customer, an insurer or a regulator has asked what controls sit around your AI, and the honest answer is that nobody has written them down in one place.
The model was evaluated once, before launch, and your data has moved since. With no held-out set in the pipeline, a customer will notice the drop in quality before you do.
What We Deliver
Each one produces evidence you can hand over. Between them they cover what a security review, a customer questionnaire and an auditor will ask you for.
01
Every AI system you run or plan is inventoried and classified by what it decides, who it affects and what a wrong answer costs. Classification is what keeps the rest proportionate. A document summariser and a system that influences a lending decision should not carry the same controls, and programmes that apply one standard to both tend to grind to a halt.
Talk to our service experts02
Models, retrieval layers and logs deployed inside your own VPC or on your own hardware, so regulated data stays where it is allowed to be. Sometimes a hosted model is simply better for a use case. When that happens we put the trade-off and the contractual position in front of you and let you decide.
Talk to our service experts03
Retrieval that respects the permissions your source systems already enforce. Identity flows through to every retrieval path, so a document somebody could not open yesterday is still closed to them through the assistant. Without this, the model quietly becomes the one place in your estate where row-level security stops applying.
Talk to our service experts04
A held-out evaluation set built from your own data, scored before every release, plus adversarial testing for prompt injection, data exfiltration, jailbreaks and the bias patterns your use case is exposed to. The point is that the pipeline notices a drop in quality first. At the moment, for most teams, a customer does.
Talk to our service experts05
Prompt, retrieval, output, model version and reviewer captured for every consequential decision, retained on your schedule and queryable. Somebody will eventually ask why the system said what it said, six months after it said it. You want to be able to look that up.
Talk to our service experts06
Your AI usage policy, model cards, data protection impact assessments and control documentation, written against the frameworks you answer to and in the form your auditors expect. We draft it for your own legal and risk teams to review and sign off.
Talk to our service expertsFrameworks
We design controls and produce evidence against these. We are not a certification body. The assessment is still made by your auditor, your regulator or your counsel. Our job is that you walk into it prepared.
Risk classification per system, the technical documentation and logging duties that follow from it, and a gap list against the dates that apply to your classification.
Lawful basis for training and inference data, data minimisation in retrieval, retention on your schedule, and a data protection impact assessment where the processing warrants one.
Protected health information kept inside your boundary, access logged at the individual level, and business associate obligations reflected in how the system is built rather than only in the contract.
Controls designed so your AI estate is evidenced by the same logging, change management and access review your existing report already relies on.
An AI management system shaped to the standard: policy, roles, risk process, supplier controls and the review cadence that keeps them current.
Govern, map, measure and manage, applied as a working practice. Worth doing even where no regulator asks for it, because it is the vocabulary most enterprise risk teams now speak.
How We Work
Five stages. Most of the first one is finding systems nobody told you about, and most of the last one is making sure the whole thing is still true in a year.
Step 1
What we do: We find every AI system in use, including the ones bought on a departmental card and the ones a team built quietly, then classify each by decision impact and data sensitivity. The list is usually longer than anyone expects.
Step 2
What we do: Per system: what could go wrong, who it affects, how likely it is, and what the exposure is. It comes out as a risk register your existing risk function can absorb, in the format they already work in.
Step 3
What we do: Deployment boundary, access model, evaluation requirement, human review points, logging and retention, each proportionate to the classification. Your security and legal teams are in the room while we design them.
Step 4
What we do: Build the evaluation set, score the system against it, then attack it on purpose: prompt injection, exfiltration attempts, jailbreaks, and the bias cases your use case is exposed to. Whatever we find goes back into the controls.
Step 5
What we do: Controls wired into the pipeline, dashboards for drift and quality, and a review cadence with named owners. A governance programme that lives only in a document tends to be out of date within two quarters, so as much of it as possible goes into CI.
Deliverables
Six artefacts, all of them yours, written for the people who get asked for them: your CISO, your DPO, your auditor and your board.
01
Every system in use or planned, with owner, purpose, data touched and classification against your risk tiers.
02
Per system: the failure modes, who they affect, likelihood, exposure and the control that addresses each.
03
The deployment, access, evaluation, review and logging requirements for each tier, written so they can be enforced.
04
A held-out set built from your data, plus the adversarial cases, wired into the release pipeline as a gate.
05
Model cards, data protection impact assessments and control evidence, in the form your auditors expect.
06
Who owns each system, who approves a model change, and when each control comes up for review. Real names and real dates against each one.
Expert Insights
I have read a lot of AI policies written as principles. Nobody argues with them, and nobody can be audited against them either. What survives a real review is narrower and considerably duller. This system is tier two, so it deploys inside the boundary, it logs these fields, this named person reviews these decisions, and the evaluation runs before every release. Duller is the point.
How We Engage
One system through a review, a whole estate brought under control, or the controls designed into something we are already building for you.
01
One system taken through classification, control design, evaluation and documentation so it can clear your internal review, for a fixed fee. This is where most people start, usually because a build is finished and stuck.
02
Inventory, classification, risk register and control framework across everything you run, plus the review cadence and ownership that keeps it current. We scope it after a short discovery.
03
Where we are building the system, the controls, evaluation and documentation go in from the first sprint. There is no separate line item for it.
Industries
Why Choose Us
Sphinx has completed 16 successful years in the industry, helping businesses with technology and digital transformation, including AI-powered solutions across major industry verticals.
We have a dedicated and reliable team of AI engineers, ML scientists, data engineers, and MLOps specialists covering every role in the AI development lifecycle.
We have delivered more than 1,500 solutions through a results-driven approach, many to recurring clients who keep expanding their AI capabilities with us.
We have a dedicated in-house team, experienced and skilled across AI development, software engineering, QA, DevOps, and cloud infrastructure.
We are trusted by 750+ clients for best-in-class AI solutions at competitive rates, with the delivery accountability enterprise clients demand.
Our client-centric approach and high-calibre AI engineering, built on current models and frameworks, have made us a trusted partner for businesses building AI.
Connect with us
Certification, deployment boundaries, keeping one user out of another user’s data, and what human review actually involves day to day. Get in touch.
No, and be careful of anyone who says they do. Certification against a standard comes from an accredited body, and compliance with a regulation is a legal judgement your counsel makes. What we do is design and implement the controls, build the evidence, and write the documentation in the form an auditor expects, so that the assessment you go through is one you are prepared for.
Yes, and for regulated clients that is the default. The model, the retrieval layer, the vector store and the logs all sit inside your network boundary. If a hosted model would genuinely serve a use case better, we will say so and show you the trade-off. The decision stays yours.
Identity flows through to every retrieval path, so the assistant enforces the permissions your source systems already hold. The alternative, a single flattened index that ignores them, is how most leaks of this kind happen. If a user could not read a document before, they cannot read it through the assistant, and the retrieval log shows what was reached on whose behalf.
A named role, a defined queue, a service level and a record. Which decisions need it is set by the classification, so a summariser does not carry the same burden as a system influencing an outcome for a person. If the review is not staffed and measured, you have written a policy and called it a control.
It should extend it. Most of what AI governance needs already exists in your programme: change management, access review, logging, supplier assessment. It just does not contemplate models yet. We map the AI estate into the controls you have and add only what is genuinely new.
Yes, and usually that is most of them. Vendor tools, embedded features in software you already licence, and things built internally all enter the same inventory and get classified the same way. The controls end up different, because your leverage over a vendor is different, but everything goes on the same register.
