AI you can put in front of an auditor.
Readiness assessment, agent and automation development, and the governance layer that lets you deploy it in a regulated environment.
The buyer's challenge
The pilot worked. That is the problem.
The pilot worked. That is usually the problem. A demonstrable model exists, leadership has seen it, and now someone has asked who signed off on the training data, what happens when it is wrong, and which control framework it maps to — and the project stops.
The gap is rarely modelling capability. It is assurance: data lineage, evaluation evidence, human-review design, and a documented management system. Very few suppliers sell the second half, which is precisely the half that gets a system into production in the public sector.
What we do
Capabilities in this practice.
AI readiness assessment
A structured review of data, process, skills and risk posture, ending in a prioritised list of what is worth automating and what is not.
Agent & automation development
Retrieval systems, document processing, workflow agents and integrations, built with evaluation harnesses so behaviour can be measured rather than demonstrated.
AI governance
Policy, risk register, model inventory, human-oversight design and control mapping to the NIST AI Risk Management Framework and ISO/IEC 42001.
Evaluation & assurance
Test sets, acceptance thresholds, regression monitoring and drift detection — the evidence an assessor or an internal audit function will ask for.
MLOps
Versioned data and models, reproducible training and deployment, and rollback paths that were tested before they were needed.
Adoption & change
Role-based enablement so the people expected to use the system actually can. Delivered with our training practice rather than as a slide deck.
What you receive
Deliverables.
- AI readiness report with a prioritised opportunity list
- Model and use-case inventory
- Risk register mapped to NIST AI RMF functions
- Working automation with an evaluation harness
- Human-in-the-loop review design
- AI management-system documentation aligned to ISO/IEC 42001
- Role-based enablement materials and delivery
How we deliver.
Frame
Identify decisions the organisation actually makes, and which of them a model could support. Use cases without a decision behind them are removed here.
Govern first
Risk register, oversight design and acceptance thresholds are agreed before the build, not retrofitted when procurement asks.
Build with evaluation
Every increment ships with its test set and measured results. If the numbers do not clear the agreed threshold, it does not ship.
Operate & monitor
Drift detection, review queues and a defined path for handling a wrong answer in production.
Methods & technologies
What we build with, and what we build to.
Standards listed here are frameworks we design and document against. They are a description of how we work, not a claim to be certified against them — our actual certification status is published in full on the certification roadmap.
Frameworks we design to
- NIST AI RMF 1.0
- ISO/IEC 42001:2023
- ISO/IEC 23894
- EU AI Act risk tiers
Engineering
- Retrieval-augmented generation
- Evaluation harnesses
- Model versioning
- Drift monitoring
Platforms
- AWS
- Microsoft Azure
- Google Cloud
Outcomes & sectors
What changes.
Stated as capability, not as a percentage. We do not publish performance figures we cannot attribute to a named engagement.
- A defensible answer to “who signed off on this model”
- Measured behaviour instead of a demonstration
- A documented oversight path for incorrect output
- Governance artefacts that survive an audit or an ATO review
Sectors we deliver into.
- Government
- Health & human services
- Financial services
- Education
- Logistics
- Nonprofit
North American public-sector codes
- NAICS 541511
- PSC D399
- PSC R425
Questions
Do you hold ISO/IEC 42001?
No. We design and document to it, and it is on our published certification roadmap with a target date. We will not describe ourselves as certified against a standard we have not been audited to.
Can you work with our existing model or vendor?
Yes. A large part of this practice is putting governance and evaluation around systems somebody else built, including commercial vendor products.
What if the honest answer is that AI is the wrong tool?
Then that is what the readiness report says, and it will name the cheaper alternative. That has happened, and it is a better outcome than an automation nobody trusts.
The rest of the loop
This pillar is one part of a delivery loop.
Have a requirement in AI Enablement & Automation?
Send the solicitation, statement of work or role description. You will get a direct answer on fit, including when the honest answer is that we are not the right supplier.