Page 135 - CyberSecurityEssentialsEnglish

Licenses, Data Policies, and Versions
Reading about quality alone is not enough to adopt a product. Examine the terms governing
inputs and outputs: is the data used to improve the service? Is there an option to disable

that? What is the retention period? Where is the data stored? Who are the subprocessors?
And do the terms differ between an individual account, an enterprise account, and the API?
Do not infer an organizational policy from a marketing screen; return to the contractual

document or the administrative setting. Published risk frameworks for generative AI help in
reading these risks within the context of use and local testing, rather than as a substitute for
the organization’s own assessment [16].

The license determines what may be done with the outputs, the weights, or the code. In

open-weight models, read the restrictions on commercial use, distribution, the number of
users, and prohibited domains. In specialized tools, examine ownership of files and

templates and the right to export data when the contract ends. An exit plan is part of the
choice, not a future problem.

Version management matters because a single alias may point to a version that changes.
Look for a dated version, a deprecation policy, a notice period, and the ability to pin a

release. When pinning is not possible, keep automated or periodic acceptance tests. Record
any change in limits, prices, context, or tools; an announced improvement on a benchmark
may come with a change that does not suit your workflow.

Compare the level of service as well: availability, rate limits, response time, support,
recovery, and security reporting. A task that runs once a week is not the same as a public
service that needs continuity. Do not pay for an enterprise tier you do not need, and do not

rely on a consumer service for a process that cannot tolerate interruption or the loss of a
record.

● A short checklist before adoption
Data policy, retention, place of processing, license, ownership of outputs, version, change

notice, export, service limits, and an exit plan.

● Remember: Section summary
• Key idea: Provider documentation tells you what was measured and under what
conditions, not what will happen in your context.
• Practical decision: Read the scenario, the data, the measures, the version, the limits,
the license, and the data policy, then test locally.

• Mistake to avoid: Reading a benchmark score as a promise about your own task.

134