Page 373 - CyberSecurityEssentialsEnglish

8.6 The Lifecycle of a Responsible Use, From Idea to Retirement
◆ Key idea: approval is the beginning of a cycle, not its end.
Approving a tool once is not enough. Models, data, interfaces, prices, and vendor terms
all change, so an organization needs decision gates and monitoring throughout the
lifecycle.

The cycle begins by registering the use case, not by buying the tool. Define the problem, the
beneficiary, the expected outcome, the process owner, the data, the current alternative,

and what success would mean. This description prevents projects that go looking for a
problem after the technology has been chosen.

Next comes the impact assessment. Published guidance provides direction for identifying,
assessing, and documenting the effects of an AI system on individuals, groups, and society

across the lifecycle [4]. A good assessment does not stop at a generic risk list; it ties each
effect to the context of use, the affected groups, the controls, and the person responsible
for follow-up.

Before release, the organization needs an acceptance test proportionate to the level of risk.

It covers task quality, reliability in ordinary and edge cases, security, privacy, bias, how usable
the interface is, and whether people can understand the signals that matter. In generative
systems, hallucination, sensitivity of outputs to the wording of a request, handling of

sources, and response to harmful or misleading content should all be tested, drawing on
published risk profiles for generative AI [13].

After testing comes a bounded pilot on a known scope, with trained users, limits on data and

permissions, and a rollback plan. A pilot is not judged successful because it attracted people;
it is successful because it produced a measurable result without exceeding the accepted
level of risk. A decision then follows: scale, revise, or stop.

After release, monitoring begins and does not end. Define the performance and risk

indicators, the alert thresholds, who responds, and how often the system is reviewed. The
capacity to see what a system is actually doing while it runs, through traces, logs, cost,
latency, and recorded failures, is usually called observability, and a system that cannot be

observed cannot honestly be said to be governed. Every material change in the model, the
source, the data, the integration, or the purpose triggers a change review, because a system
that was suitable yesterday may become unsuitable after a vendor update or a move into a

new function.

The cycle ends in retirement or shutdown. Decide in advance how you will revoke
permissions, which records you will keep, how you will transfer the data, how you will inform
users, how you will replace the function, and how you will stop unapproved copies persisting.

372