A launch assessment describes a moment.
The model, prompt, index and permissions that were tested are often not the ones in production a quarter later. The report is still in circulation anyway.
Services /Continuous AI
Continuous AI
Assurance
Keep assurance current as your AI system changes after deployment.
Discuss ongoing assuranceKeep confidence as systems change.
An assessment captures a system at a moment in time. Model updates, new data and expanded tool access can change behaviour. An ongoing assurance programme tests meaningful changes and checks whether controls still hold.
Continuous assurance is a recurring engagement for a system that is already in use. Models are updated, prompts are edited, new sources are connected and tool access expands. Any of those can move the behaviour an earlier assessment described.
We agree what will be watched, which changes trigger a test, and how findings reach the people who still own the risk. The programme is set to the system and to how often it changes. It is not a claim that every regression will be caught, and it does not replace the operational monitoring you run yourselves.
The assessment ages.
The system does not wait.
New data changes what the system can say.
A broader index, a new repository or a refreshed corpus can surface material the original tests never reached, without anyone treating that as a new deployment.
Permissions widen in small steps.
An extra tool, a shared mailbox or a higher role rarely receives the scrutiny given to the original design, even when the practical access is larger.
Nobody owns the next test.
After the project team moves on, it is unclear who decides that a vendor update, a prompt edit or a new integration needs to be looked at again.
System-specific.
Evidence-led.
- 01Model and vendor updatesWhether a model change, a provider update or a new default setting has moved behaviour relative to the last assessed baseline.
- 02Prompt and configuration changesHow edits to instructions, guardrails, tools and settings alter what the system will do, including changes that look administrative.
- 03New data sources and retrieval behaviourWhat a new or expanded source makes available, and whether retrieval still respects the boundaries agreed at the outset.
- 04Integrations and tool permissionsWhether added tools, connectors or roles have widened what the system can read, send or change.
- 05Behavioural regressions and emerging failuresWhether previously sound behaviour has degraded, and whether new failure modes have appeared in real use.
- 06Oversight and control effectivenessWhether human review, logging, approval steps and other controls still operate as the system and its use have evolved.
A clear path
through assurance.
01
Record the system you are assuring.
The current model, configuration, data sources, tools, oversight and open risks become the reference for later comparison.
Confidence that keeps pace with change.
- Agreed monitoring and retesting planThe changes that trigger a test, the schedule for everything else, and the people who receive and act on results.
- Recurring technical assessmentsRepeatable tests against the live system, scoped to the behaviour that matters for its current use.
- Change-triggered testing findingsResults from tests prompted by a model, prompt, data or permission change, with the change identified.
- Updated evidence and risk registerThe current view of findings and residual risk, replacing the launch pack as the record of the system.
- Remediation trackingWhich earlier findings have been addressed, which remain, and which need a retest before they can be closed.
- Regular assurance reviewsA periodic discussion of what changed, what was tested, what was accepted and whether the programme still fits.
Deliverables and testing scope are agreed at the start of the engagement.
Assurance that still
describes the system.
A record that matches what is running.
Decision-makers are not left citing a launch assessment after the model, the data or the permissions have moved on.
A reason to retest, agreed in advance.
Material changes have an owner and a trigger, rather than waiting for a user to notice a regression.
Regressions with evidence attached.
When behaviour shifts, the finding says what changed, what was observed and what should be done, including where a retest is needed.
A programme sized to the system.
Cadence and scope follow how the system is used and how often it changes. The engagement does not pretend to watch everything.
Built around
your responsibility.
Organisations operating AI in business-critical environments and vendors maintaining enterprise AI products. Engagements are tailored to the system, change frequency and risk profile.
- 01The launch assessment is already out of date.The system has had a model update, a prompt rewrite or a new data source, and the report people still circulate describes the earlier version.
- 02Access has grown since go-live.Tools, connectors or roles have been added in the course of ordinary work, and nobody has re-examined what the system can now do.
- 03A product keeps shipping.A vendor maintains an enterprise product whose behaviour changes with releases, and buyers expect the assurance to move with it.
Where this sits.
Continuous assurance follows a deployment or a product that is already in use. Deployment assurance is the test before that first decision. Deployment support is the work while the system is still being designed. Product assurance is the independent view a vendor takes to enterprise buyers.
01
AI Deployment Assurance
Independent testing before AI enters your organisation’s workflows, data and decisions.
02AI Product Assurance
Independent validation for AI vendors preparing their products for enterprise use.
03AI Deployment Support
Independent guidance and testing alongside your team throughout implementation.
Deploy AI with confidence.
Start a conversation about your system, what it needs to do and what you need to know.