Structured observation
Available records, software configurations, procurement information and working practices were examined to establish how AI had entered the organisation.
This case example is illustrative. It does not describe a real client engagement and it does not identify any organisation, system or vendor.
It describes a composite organisation in order to show how an independent AI Security Risk Assessment moves from structured observation to supporting evidence, and from evidence to organisational implications.
A mid-sized organisation with several professional service teams and a small internal technology function.
No formal AI programme existed. Artificial intelligence had entered the organisation gradually through software updates, individual experimentation and one departmental procurement.
Leadership requested an independent assessment in order to understand what was already in use before deciding how to govern it.
These are initial observations, not findings. Each is stated plainly, without interpretation, and none was treated as established until evidence supported it.
Available records, software configurations, procurement information and working practices were examined to establish how AI had entered the organisation.
Each observation was supported by documentary or configuration evidence before it was carried forward into analysis.
Observations were considered together, revealing patterns that were not visible when each AI tool was viewed in isolation.
The combined evidence was translated into implications for information handling, governance, oversight and operational dependence.
The initial observations raised several plausible concerns. Each was tested rather than assumed to be true.
Where available and appropriate, the assessment drew on software and account records, procurement records, identity and access arrangements, administrative configurations, relevant policies and employee guidance, supplier documentation, available usage information, interviews and structured discussions with representative staff, and examples of working practices, where these could be examined without unnecessarily exposing confidential information.
Some of what follows describes exposure. Some of it simply describes the characteristics of the environment — characteristics that matter when trying to understand where exposure might sit.
A plausible concern is not the same as an established finding.
Not every concern raised early in the assessment survived contact with the evidence.
The clearest example concerned the AI functionality in the existing document platform. A reasonable initial concern was that the new feature might automatically expose or transfer all organisational documents into an external AI processing environment. That question was examined directly, through relevant configuration information and supplier documentation.
The available evidence did not support that conclusion. The evidence examined did not indicate that documents were automatically transferred to an external model simply because the feature had become available.
This did not resolve every question about the feature. It meant only that this particular concern was not supported strongly enough to be carried forward as a finding.
An independent assessment should be capable of setting aside an initial concern when the evidence does not sustain it. Otherwise the work becomes an exercise in confirming suspicion rather than understanding the environment.
The absence of evidence for these conclusions was itself important. Cybersecurity analysis should not convert uncertainty into certainty simply because a risk is plausible.
Implications follow from the combined evidence. Each is set out with the reasoning that produced it, so that the step from evidence to implication can be examined rather than taken on trust.
Information entered into AI tools extended beyond the boundaries the organisation believed applied.
Access arrangements differed between services, and some depended on individually created accounts. Combined with the drafting and summarisation work observed, internal material was passing through environments the organisation had not recorded as part of its information handling picture.
Governance had not yet developed at the same pace as adoption.
This did not follow simply from the number of AI tools present. Adoption had developed through three different routes — individual use, embedded software functionality and one departmental procurement — while governance remained based on a much narrower understanding of how AI was entering ordinary work.
Accountability for AI-related decisions was unclear at leadership level.
This is not a generic governance criticism. Each part of the environment fell under a different existing responsibility: procurement sat with a department, platform updates with the technology function, and day-to-day use with individuals. Nothing in that arrangement produced a single view of overall AI exposure.
Some routine work had become dependent on AI-assisted processes without that dependence being recorded.
Where summarisation and drafting had become part of a normal working sequence, the work was shaped by tools that appeared in no register of systems the organisation relied upon.
Which AI systems does the organisation consider approved, and who decides?
What information is permitted to be entered into AI tools?
Who is accountable when an AI-assisted process produces an incorrect result?
How will the organisation become aware of AI features introduced through software updates?
Where human oversight is expected, how is it recorded?
The assessment did not indicate that the organisation had experienced a major AI-related security incident. Nor did it indicate that AI adoption had taken place through one clearly defined organisational programme.
AI capability had entered through several different routes and had become part of ordinary work before the organisation developed a complete view of where it was being used, what information it interacted with, and where responsibility for those decisions sat.
The principal security issue was therefore not the presence of AI technology. It was the distance between the organisation's understanding of its AI environment and the environment that had developed in practice.
Before the organisation could decide how AI should be governed, it first needed a clearer picture of the AI environment it already had.
This is not a record of a client engagement.
It does not identify any organisation, individual, system or vendor.
It does not describe findings that apply to any particular organisation.
Every assessment is different. The methodology remains the same, and the scope is agreed before work begins.
Organisations considering an independent review of how AI is being used across their environment can contact Cyber Analysis to discuss the question they are seeking to understand and whether an AI Security Risk Assessment would be appropriate.
Contact Cyber Analysis