How to run a safe first AI pilot in security, safety or resilience
A first AI pilot should not be an impressive demonstration in search of a problem. It should test whether AI can improve one real operational workflow, using approved information, explicit human review and evidence that supports a decision.
For security, safety and resilience teams, the consequences of weak advice, missed information or misplaced confidence can be serious. Starting small is sensible, but small does not automatically mean safe. The pilot needs boundaries, realistic test cases and a clear point at which a person checks the result.
Start with one operational question: can this defined workflow be improved without weakening the controls or judgement on which it depends?
1. Decide what the pilot must prove
Consider a safety team that reviews contractor risk assessments and method statements (RAMS). Submissions vary in completeness. Reviewers must compare documents with site requirements, identify gaps and decide what needs clarification before work begins.
The useful first question is not whether AI can approve RAMS. It is whether AI can support a first-pass RAMS review: find potentially missing controls, identify inconsistencies, point reviewers to relevant passages and prepare a draft list of questions. A competent person still checks those findings and decides what happens next.
A demonstration shows what a system can produce in favourable circumstances. A pilot should establish how it performs on representative operational material, including incomplete and difficult examples, and what resources and controls it would require in use.
2. Choose a consequential but bounded workflow
Good first workflows are not necessarily frequent. An emergency procedure may be used rarely but justify rigorous testing because its consequences are high. What matters is that the task is worth improving and can be evaluated within defined limits.
- Consequential: mistakes, delays or omissions have a meaningful operational cost.
- Bounded: inputs, sources, outputs and exclusions can be described.
- Repeatable in method: the same evaluation approach can be applied across cases, even if incidents themselves are infrequent.
- Measurable: expected benefits and unacceptable failures can be defined in advance.
Examples include procedure retrieval, report triage, draft handovers, document assessment and pattern finding across incident records. An ambition such as “use AI to manage the control room” is too broad for an initial controlled test.
3. Set boundaries before running the test
Write a brief pilot control specification before presenting any outputs to users. This should identify what the system may access, what it may produce and what it must not do.
| Control | Example for a RAMS pilot |
|---|---|
| Permitted inputs | Agreed sample contractor RAMS and the relevant current site review criteria. |
| Excluded material | Unapproved, obsolete or unnecessary personal information and documents. |
| Permitted output | Potential gaps, cited document passages and a draft reviewer summary. |
| Prohibited action | No autonomous approval, rejection, instruction to commence work or alteration of the original submission. |
| Human responsibility | The appointed competent reviewer checks findings and decides whether to request changes or escalate. |
| Evidence record | Input version, review criteria, output, supporting passages, reviewer corrections and final disposition. |
| Failure handling | Unsupported claims, missing evidence or uncertainty are flagged for correction and review, not silently accepted. |
Use information the organisation is permitted to process, with appropriate access, retention and privacy arrangements. Where personal or sensitive data are involved, complete the necessary governance and assurance steps before testing. Keeping a pilot outside live decision-making can reduce risk, but it does not remove data-protection responsibilities.
4. Design the evaluation before testing
Agree the baseline, evaluation cases and acceptance thresholds before seeing the AI outputs. Otherwise, there is a temptation to declare success based on impressive examples while overlooking failures.
Include straightforward examples, incomplete submissions, ambiguous language, conflicting criteria and cases where the right answer is to acknowledge insufficient evidence. Compare the AI-assisted process with the existing process, not with an idealised benchmark. Involve operational reviewers, the workflow owner and relevant assurance colleagues.
5. Worked example: an AI-assisted RAMS review
Illustrative scenario, not a reported deployment result. A contractor submits RAMS for maintenance in a live plant area. The reviewer normally checks completeness and site fit, seeks clarifications and decides whether the submission is acceptable.
- Input: the agreed RAMS and current site-specific criteria are provided within the pilot scope.
- First pass: AI flags an unclear isolation sequence and generic emergency arrangements, citing the relevant passages or noting where required information cannot be found.
- Verification: the competent reviewer checks each observation against the original RAMS, the relevant criteria and operational conditions.
- Judgement: the reviewer identifies an additional sequencing risk that the AI did not capture fully and determines what clarification is needed.
- Record: the team retains both the AI observations and the human corrections, including any missed issues.
The point is not that the AI produces a complete safety assessment. It is that the reviewer may reach relevant evidence more efficiently while retaining responsibility for the substantive judgement. For a separate worked example, see AI for RAMS review: where it helps, where it does not.
6. Measure benefits and failures together
Time saved matters, but a faster process that misses serious issues is not an improvement. Capture the work required to verify and correct AI outputs. Record false positives and false negatives, not just examples of correct findings.
| Measure | What the pilot should examine |
|---|---|
| Accuracy and omissions | Correct findings, missed material issues, false alarms and severity of errors. |
| Effort and elapsed time | Time from input to verified outcome, including human checking, revisions and rework. |
| Evidence quality | Whether observations are traceable to the right approved source and passage. |
| Review effectiveness | Whether users can detect, challenge and correct errors rather than simply endorse the output. |
| Operational usability | Whether outputs fit the actual work and help rather than interrupt users. |
| Deployment burden | Data preparation, integrations, security assurance, support and ongoing maintenance. |
Set minimum acceptable standards before the test. A pilot is successful only if its benefits are supported by evidence and its residual risks are acceptable to the operational owner.
7. Make a documented deployment decision
A first pilot should end with a decision rather than become an indefinite experiment. It can be useful even when the decision is not to proceed: the test may reveal weak documents, inconsistent review criteria or gaps in the existing workflow.
A practical first-pilot specification
Before authorising a pilot, confirm that the following are written down and agreed:
- Operational problem and accountable owner
- Task boundaries and prohibited actions
- Approved input and reference sources
- Data handling and assurance arrangements
- Baseline process and representative cases
- Named reviewers and escalation route
- Metrics, error categories and acceptance thresholds
- Evidence retention and decision date
The strongest first pilot is not the one with the most features. It is the one that leaves the organisation better able to explain what was tested, what was learned, who made the decision and what should happen next.
Run a practical SIRV AI trial
SIRV AI focuses on purpose-designed operational workflows, including document evaluation, procedure access, triage, investigation support and retained learning. A bounded trial can establish whether a specific workflow is worth taking further, with sample outputs, review findings, measured outcomes where possible and a recommendation to implement, refine or stop.
Explore a SIRV AI trialFrequently asked questions
What makes a good first AI pilot?
A real, bounded operational task, an approved evidence base, a named human reviewer, realistic cases and pre-agreed success and failure criteria.
Should the first pilot aim to automate decisions?
Usually not in consequential security, safety or resilience work. Start by evaluating support for retrieval, assessment or drafting while operational decisions remain with authorised people.
Must the workflow happen frequently?
No. A rare but high-consequence workflow can justify testing if its method is sufficiently defined and realistic cases can be evaluated.
How do we assess whether AI is safe enough?
Define the relevant risks, data controls, prohibited actions, acceptable error thresholds, human checks and escalation points before testing. A pilot cannot prove absolute safety.
What should be measured?
Accuracy, omissions, end-to-end effort, evidence traceability, reviewer effectiveness, usability and implementation requirements. Evaluate failures as carefully as apparent benefits.
What happens when the pilot ends?
The accountable owner should record whether to proceed, revise or stop, supported by findings and an assessment of what deployment would require.
