AI & Machine Learning
AI governance and compliance
An inventory of every AI system actually running, a risk register, and technical files written to survive a compliance review.
- From
- $2,000–$20,000
- Typical time
- 3–8 weeks
- Usually bought by
- Regulated industries
What this actually solves
Two different pressures bring companies here and they need different answers. The first is legal: regulation now exists, it sorts AI systems into risk tiers with obligations attached to each, it prohibits some uses outright, and the penalties are set as a share of global turnover rather than as a fixed sum. The second is more immediate and far more common in banking, insurance, healthcare and legal services — a system is built, it works, and it cannot go into production because compliance has not signed it off and nobody has given compliance anything they can sign.
That second situation is where most of the money is quietly lost. An engineering team has delivered something that does its job, and it sits in staging for a quarter while emails go back and forth, because the compliance officer is being asked to approve a system they have been given no description of. They are not obstructing anything. They are being asked to take personal responsibility for a black box, and the correct answer to that request is always no.
What unblocks it is documentation of a particular kind, and this is the honest boundary of this service. Governance has a legal half and a technical half, and we do the technical half. Your solicitor or compliance officer writes the legal opinion — they are qualified to and we are not. What they cannot write, because they were not in the room when the thing was built, is the file describing what the system actually does. That is ours, and it is the document the legal opinion has to sit on top of.
What we do, and in what order
- Inventory, including the systems nobody declared. Department by department, not just through IT. The count that comes back is reliably higher than the number the company started with, because tools get expensed on individual cards, staff paste customer data into consumer chat products, and vendors add model-powered features to software you already pay for. Every entry gets an owner, a purpose and a data description. About a week.
- Classification and a risk register. Each system is placed against the regulation's tiers and against the frameworks your auditors will recognise — NIST's AI Risk Management Framework and ISO/IEC 42001 are the two that come up most. For each one: what can go wrong, who it affects, how badly, what currently prevents it, and what should. Three to five days.
- A technical file per high-risk system. Nine sections, and each one exists because somebody will ask for it. Purpose and explicit limits, including what the system must not be used for. Model, version and provider. Data — what goes in, where it is stored, in which region, for how long, and who can read it. The human's role, including what information they actually see at the point of decision. Testing method, case count and results. Known weaknesses and what mitigates each. Monitoring, thresholds and who receives the alert. The incident path when an output is wrong. And change management. One to two weeks, depending on how many systems qualify.
- Vendor and data-flow review. What each provider's current terms say about where your data goes, whether it is used for training, which plan that depends on, and what the contract commits them to. These terms change, so the file records the version and the date it was read rather than asserting a permanent fact. Three to five days.
- Policy, oversight and the handover pack. Who may use what, which categories of data may go where, how a new AI tool gets approved before somebody buys it, and how the whole set gets reviewed on a cycle. The pack closes with the questions a compliance officer will put to this documentation, answered in advance, so the review meeting is a review rather than a discovery exercise. Three to five days, plus your legal review.
What moves the price
The range is $2,000–$20,000 over 3–8 weeks, and it is driven by three things.
How many systems clear the high-risk bar. Low-risk tools need a register entry and a policy line. A system that influences a decision about a person needs the full nine-section file, evidence of testing and a documented oversight arrangement. The count of the second kind is most of the estimate.
Which regulator you answer to, and where. A firm operating inside the EU carries obligations a purely domestic one does not, and financial services, healthcare and insurance each add their own supervisory expectations on top. More regimes means more evidence, not just more paperwork.
Whether this is documentation or remediation. Sometimes the file cannot be honestly written because the control it should describe does not exist — no human review step, no logging, no way to reconstruct why a decision was made. Building that first is a different and larger piece of work, and we say so before quoting rather than after.
What usually goes wrong
Somebody writes the word compliant. It appears in a summary line, in an email, in a slide, and it converts a technical deliverable into a legal assertion made by a party with no standing to make it. If the regulator later disagrees, that sentence is now evidence. The sentence that does the same job safely is that the documentation has been prepared in the form the compliance process requires, and that confirmation comes from counsel.
The inventory only counts what IT knows about. The register is produced from the software asset list, it is internally consistent, it looks complete, and it omits the recruitment tool one manager subscribed to and the consumer chat product customer service staff use on their own accounts. A register that is complete on paper and wrong in fact is worse than no register, because it converts an unknown risk into a documented assurance.
The file is written once and then quietly expires. Six weeks after handover somebody rewrites the system prompt, the provider ships a new model version, or a second data source is connected — and the documentation now describes a system that no longer exists. This is specific to AI systems and it is why the change management section is not filler: it names which changes trigger a re-test and a file update, and who is accountable for doing it.
See where the site stands before you brief anyone.
If the site is already live, start from what it scores rather than from a guess. The audit reports what it checked, what it found, and — the part most tools leave out — what it could not check, and why.
Questions people ask before they commit.
- Can you certify that we are compliant with the EU AI Act or GDPR?
- No, and you should be wary of anyone who says they can. We are not lawyers, and a sentence like that in a deliverable becomes a written recommendation from an unqualified source. What we write instead is this — the technical documentation has been produced in the form your compliance process requires, and legal confirmation comes from your compliance officer or your solicitor. That distinction protects you as much as it protects us.
- So what is the part you actually do?
- The technical half, which is the half a legal advisor cannot write. What each system does and specifically does not do, which model and version, where the data goes and for how long, where a human makes the decision and what they can see when they make it, how it was tested and on what, its known weaknesses, what is monitored, and what happens when it produces a bad output. Your lawyer writes the legal opinion on top of that file.
- We only use one or two AI tools. Is an inventory really worth it?
- The inventory almost always comes back larger than the number the company gave us at the start, usually by several times. Individual departments sign up for their own tools on a card, staff paste customer information into consumer chat products, and a vendor quietly adds a model-powered feature to software you already licensed. You cannot govern or classify what nobody has written down.
- What makes a system high risk?
- The regulation sets tiers, and systems that make or materially influence decisions about people — recruitment, credit, insurance, access to services — attract the heaviest obligations around documentation, human oversight and transparency. Some uses are prohibited outright. Penalties are set as a percentage of global turnover, which is why this stops being an IT question at board level.
- Can you do this for a single system rather than the whole company?
- Yes, and for many firms that is the right first purchase — the one system that compliance is currently blocking. Per-system technical documentation is the smallest useful unit of this work and is quoted that way. The full inventory, risk register and policy set is the larger engagement.
- What happens when we change a prompt after you have gone?
- That is exactly what the change management section is for, and it is the part that decides whether this documentation is still true in a year. It defines which changes require the file to be updated and re-tested — a model version bump, a prompt rewrite, a new data source — and who signs that off. Without it the file quietly stops describing the system it was written about.
Often taken together.
Start with the brief, not the invoice.
Send what you are trying to achieve. You get a written scope, a price and a date — or an honest “this is not the right service for that”.
Talk about AI governance & compliance All AI & Machine Learning services