Digital Procurement, Data, Cybersecurity and AI Law

Introduction and context

Procurement has moved from paper purchase orders and face-to-face negotiation to digitally mediated ecosystems. Organisations now source through electronic tendering platforms, exchange structured data through application programming interfaces (APIs), use cloud-based contract-management systems, authenticate signatories electronically, and apply artificial intelligence (AI) to supplier discovery, evaluation, forecasting and risk monitoring. These technologies can reduce transaction costs and improve visibility, but they also alter the legal questions involved in purchasing.

A digital procurement transaction is not merely a paper transaction reproduced on a screen. It involves questions of identity, authority, system reliability, record integrity, platform governance, data ownership, cybersecurity, automated decision-making, intellectual property and cross-border jurisdiction. A procurement professional must therefore understand both the legal validity of an act and the evidential and operational conditions that make the act defensible.

This chapter adopts a comparative and technology-neutral approach. Specific legal outcomes depend on applicable national law, sector regulation, contract wording and the facts of the transaction. Important reference points include the UNCITRAL Model Law on Electronic Commerce, the UNCITRAL Model Law on Electronic Signatures, the United Nations Convention on the Use of Electronic Communications in International Contracts, the EU General Data Protection Regulation (GDPR), the EU Data Act, the EU AI Act, the UK Electronic Communications Act 2000, the UK GDPR and Data Protection Act 2018, the United States Electronic Signatures in Global and National Commerce Act (E-SIGN), the Uniform Electronic Transactions Act (UETA), India’s Information Technology Act 2000 and Digital Personal Data Protection Act 2023, and sector-specific cybersecurity and records legislation. These instruments are not interchangeable; they illustrate recurring legal principles.

Learning objectives

By the end of this chapter, the reader should be able to:

1. distinguish electronic signatures, digital signatures, electronic records and electronic contracts;
2. design evidentially reliable digital procurement records;
3. assess platform terms, click-wrap arrangements and smart-contract mechanisms;
4. allocate data-protection, cybersecurity and cross-border transfer responsibilities;
5. evaluate electronic evidence in procurement disputes;
6. govern AI-supported sourcing and automated decisions;
7. identify confidentiality, bias, accountability and intellectual-property risks; and
8. develop practical controls for legally defensible digital procurement.

1. The legal architecture of digital procurement

1.1 Functional equivalence and technology neutrality

Modern electronic-transactions legislation commonly follows two principles. Technology neutrality means that the law should not make validity depend unnecessarily on one technical method. Functional equivalence means that an electronic method should satisfy the legal function traditionally performed by paper, handwriting, an original or a physical seal.

For example, a paper signature performs several functions: it identifies the apparent signer, indicates intention, links the signer to the document and assists later proof. An electronic signature is legally useful when it performs these functions with adequate reliability. A typed name, a scanned signature, a click on an acceptance button, a cryptographic signature and a biometric action may all qualify as electronic signatures, but their evidential strength differs.

Electronic-transactions statutes commonly address whether a record or signature can be denied legal effect solely because it is electronic. They do not necessarily make every electronic transaction valid. Other requirements may still apply: authority to contract, incorporation of terms, mandatory consumer protections, notarisation, witnessing, registration, sector-specific formality or public-procurement rules.

1.2 Electronic records

An electronic record is information created, stored, processed or communicated electronically and capable of being reproduced. A legally reliable record should normally be:

• accessible for later reference;
• retained for the legally required period;
• protected against unauthorised alteration;
• attributable to a person, system or business process;
• accompanied by sufficient metadata; and
• capable of being produced in an intelligible form.

The record is not limited to the visible purchase order. It may include the request for quotation, supplier responses, evaluation matrices, approval logs, version histories, platform audit trails, system-generated timestamps, communications, access logs and the final contract.

A PDF export alone may be inadequate if it removes the information needed to establish who approved a transaction, which terms were displayed, whether a document was altered, or whether a system clock was reliable. Procurement records should therefore preserve both human-readable content and relevant machine-readable metadata.

1.3 Electronic signatures and digital signatures

An electronic signature is a broad legal category: electronic data attached to, logically associated with or used by a person to sign a record. A digital signature is a particular cryptographic technique, usually based on a public-key infrastructure (PKI). A digital signature typically uses a private key to create a signature and a corresponding public key to verify it. A certificate authority may bind the public key to an identity.

Digital signatures can provide stronger evidence of integrity and signer control, but they are not automatically superior in every legal or commercial setting. The relevant issue is whether the method is reliable and appropriate for the risk, transaction value and applicable law.

A procurement organisation should assess at least:

The contract should specify acceptable signing methods, signature levels, authority requirements, time zones, execution counterparts and the treatment of platform-generated records.

1.4 Signature validity is not contract validity

A valid electronic signature does not cure defects in the underlying agreement. A contract may still fail because of lack of consideration where required, illegality, mistake, duress, fraud, lack of capacity, lack of authority, uncertainty, failure to satisfy a statutory formality or conflict with mandatory public-procurement rules.

Similarly, a procurement employee may authenticate successfully but lack delegated authority to commit the organisation above a financial threshold. Identity and authority are separate controls. Approval workflows should therefore combine authentication with delegation-of-authority rules and segregation of duties.

2. Digital records, retention and electronic evidence

2.1 The evidential lifecycle

Electronic evidence is persuasive when its lifecycle is explainable. The organisation should be able to show how a record was created, transmitted, received, stored, accessed, altered or deleted. A useful lifecycle is:

1. Creation: identify the originating user, system and business purpose.
2. Capture: preserve the record with relevant metadata.
3. Validation: confirm completeness, authenticity and authorisation.
4. Storage: maintain secure, access-controlled and resilient repositories.
5. Use: record subsequent approvals, amendments and disclosures.
6. Retention: apply a documented legal and business schedule.
7. Disposition: securely delete or archive records, subject to litigation holds.

A litigation hold suspends ordinary deletion when litigation, investigation or a regulatory inquiry is reasonably anticipated. Automated deletion without a hold process can create spoliation risk.

2.2 Authenticity, integrity and reliability

Courts generally evaluate electronic evidence through ordinary evidential principles, statutory rules and procedural rules. The central questions are often whether the evidence is authentic, complete, reliable and relevant. Useful evidence includes system design documentation, access-control policies, audit logs, hash values, certificate records, chain-of-custody statements, witness testimony and records of ordinary business practice.

A cryptographic hash is a fixed-length output calculated from data. If the same algorithm and unchanged data are used, the resulting hash should match. A mismatch indicates that the data or calculation context differs; it does not, by itself, prove who changed the data or whether the original was truthful. Hashing is therefore an integrity control, not a complete authenticity solution.

For high-value sourcing events, organisations should preserve:

• the exact tender version presented to each bidder;
• the time and time zone of submissions;
• bidder identity and authentication events;
• amendments and clarifications;
• evaluation criteria and evaluator access;
• automated scoring rules and model versions;
• approval and exception records; and
• system and security logs.

3. Platform terms, click-wrap and smart contracts

3.1 Platform contracting

Digital procurement commonly involves a platform provider, buyer, supplier, logistics provider and sometimes a marketplace operator. Each may operate under different terms. Contracting problems arise when terms are incorporated by hyperlink, updated unilaterally, located behind a login, presented only after performance, or inconsistent with a negotiated master agreement.

Courts typically examine notice, assent, incorporation, authority, consistency and unconscionability or unfairness where applicable. A clearly presented click-wrap agreement, requiring the user to select “I agree,” generally provides stronger evidence of assent than a passive browse-wrap arrangement. Nevertheless, a user’s click does not necessarily bind the organisation if the user lacked authority, and an incorporated term may be ineffective if it conflicts with mandatory law or an earlier negotiated contract.

Procurement teams should control:

• the version and location of platform terms;
• precedence between purchase orders, framework agreements and online terms;
• unilateral amendment rights;
• governing law and dispute forum;
• service levels, suspension and termination;
• data use, subcontracting and audit rights; and
• export and retrieval of records upon termination.

3.2 Smart contracts

A smart contract is code that performs specified actions when programmed conditions are met. It may automate payment against delivery data, release inventory after an approval event or calculate a service credit. The code is not necessarily the entire legal contract. A legally effective arrangement normally requires a conventional agreement that defines commercial obligations, while the code executes selected obligations.

A robust smart-contract arrangement should specify:

• the legal agreement and the code version;
• the source of external data, or “oracle”;
• who may update code and under what controls;
• how errors, outages and disputed events are handled;
• emergency suspension and manual override rights;
• allocation of cyber and oracle risk;
• applicable law and jurisdiction; and
• the relationship between code output and contractual interpretation.

Automation can make an erroneous result occur quickly and repeatedly. Therefore, testing, independent code review, access management and an auditable override mechanism are legal as well as technical requirements.

4. Data protection in procurement

4.1 Data categories and roles

Procurement systems process supplier contact details, employee identifiers, bank information, beneficial ownership data, credentials, performance records, location data and sometimes special-category or sensitive personal data. Data protection law generally distinguishes personal data from non-personal commercial information, although confidential business information may remain protected by contract or trade-secret law.

The parties’ roles must be analysed rather than assumed. A buyer may be a controller or business deciding why and how personal data are processed. A platform provider may be a processor acting on documented instructions, or may be an independent controller for its own purposes. Suppliers may separately control data concerning their personnel. A written data-processing agreement should address subject matter, duration, purpose, data types, security, sub-processors, assistance, deletion or return, audit and breach notification.

4.2 Core data-protection principles

Common principles include lawfulness, fairness and transparency; purpose limitation; data minimisation; accuracy; storage limitation; integrity and confidentiality; and accountability. Procurement departments should identify a lawful basis before collecting or using personal data. Consent is not always necessary or appropriate, particularly where processing is required for contract performance, legal obligation or legitimate interests. The selected basis must reflect the real purpose and applicable law.

A practical procurement privacy assessment asks:

1. What data are collected?
2. Why are they necessary?
3. Who can access them?
4. Where are they stored and transferred?
5. How long are they retained?
6. What rights can individuals exercise?
7. What happens if the data are inaccurate, exposed or no longer needed?

Privacy notices should explain relevant processing in clear language. Data-protection impact assessments may be appropriate for systematic monitoring, large-scale sensitive data, profiling or innovative high-risk processing.

4.3 Cross-border transfers

Cloud procurement systems frequently move data across borders through hosting, support, backup and subprocessors. Transfer legality depends on the origin and destination, data category, applicable transfer mechanism and government-access risks. Mechanisms may include an adequacy decision, standard contractual clauses, binding corporate rules, approved certification or a statutory derogation, depending on the jurisdiction.

Contractual clauses alone may not resolve all risk. Organisations may need a transfer impact assessment, supplementary technical safeguards such as encryption and pseudonymisation, access restrictions, transparency obligations and a process for responding to government requests. Data localisation requirements may also arise in banking, healthcare, defence or public-sector procurement.

5. Cybersecurity duties and resilience

Cybersecurity is both a technical discipline and a legal risk-control function. A procurement contract should allocate responsibilities across the buyer, supplier, platform and subcontractors. Relevant duties may arise from data-protection law, critical-infrastructure regulation, sector standards, consumer law, corporate governance, contract law and incident-reporting legislation.

A risk-based security baseline normally includes:

• identity and access management, including multi-factor authentication;
• least-privilege permissions and segregation of duties;
• encryption in transit and at rest where appropriate;
• secure software development and vulnerability management;
• logging, monitoring and alerting;
• backups and tested recovery procedures;
• supplier security assessment and continuous monitoring;
• incident response, evidence preservation and notification procedures;
• personnel training and insider-threat controls; and
• termination controls for credentials, data and integrations.

A contract should define security standards, audit rights, penetration-testing boundaries, vulnerability disclosure, subcontractor approval, breach notification timing, cooperation, remediation, business continuity, cyber insurance and liability allocation. “Industry-standard security” is often too vague unless measurable requirements are attached.

An incident-response clause should distinguish detection from notification. Immediate notification may be operationally desirable, while legally required notification may depend on a threshold and a statutory deadline. The parties should agree who investigates, who communicates with regulators and affected persons, and how privilege and confidentiality will be managed.

6. AI-supported sourcing and automated decisions

6.1 Uses of AI in procurement

AI may classify suppliers, extract contract terms, predict disruption, rank bids, detect fraud, recommend negotiation positions, generate specifications or answer procurement queries. Machine-learning systems infer patterns from data; generative AI produces text, code or other content from prompts and learned statistical relationships. Their usefulness does not remove the need for human governance.

An AI-supported procurement decision can be represented conceptually as:

Here, Data means the input information, Model means the algorithm or statistical system, Threshold means the rule for classification or action, Human Review means authorised oversight, and Context means the legal and commercial circumstances. This is not a universal legal formula; it is a governance model showing that an output depends on more than the model alone.

6.2 Risk-based governance

Contemporary AI regulation increasingly uses risk categories. High-impact applications may require risk management, data governance, technical documentation, record keeping, transparency, human oversight, accuracy, robustness and cybersecurity. Some uses may be prohibited or restricted, while others require user disclosure.

Procurement leaders should create an AI inventory identifying the system, supplier, purpose, affected persons, data, model version, decision impact, applicable law and accountable owner. Before deployment, the organisation should assess:

• whether the purpose is lawful and necessary;
• whether training and input data are representative and permitted;
• whether the system produces disparate or discriminatory outcomes;
• whether outputs are explainable enough for the decision;
• whether humans can challenge or override the result;
• whether performance is monitored after deployment; and
• whether the supplier can provide documentation, testing results and incident support.

6.3 Automated decisions and human oversight

Automated scoring can create legally significant effects, such as exclusion from a tender, adverse supplier classification or termination of a relationship. A human merely pressing an approval button is not meaningful oversight. Meaningful oversight requires competence, authority, access to relevant information, time to review, and the ability to reject or modify the output.

A procurement policy should identify decisions that cannot be made solely by an automated system, require reasons for material adverse decisions, establish appeal channels and preserve the evidence relied upon. Where privacy law grants rights concerning solely automated decisions, those rights must be integrated into the workflow.

6.4 Bias and model performance

Bias may enter through historical purchasing patterns, incomplete supplier data, proxy variables, labelling choices or objective functions that reward incumbents. Removing an explicit protected characteristic does not necessarily remove indirect discrimination if variables act as proxies.

Model evaluation should be proportionate to risk. Possible measures include error rates by relevant group, false-positive and false-negative rates, calibration, stability over time and outcome disparities. No single fairness metric is universally correct because metrics can conflict. The organisation must justify the selected measure in light of the decision purpose and applicable law.

Data quality and model performance may be expressed conceptually as:

This is a qualitative framework, not a predictive equation. It emphasises that even an accurate model in one environment may be unsafe in another.

7. Confidentiality, intellectual property and AI-generated content

7.1 Confidential procurement information

Tender prices, cost structures, designs, supplier lists, forecasts and negotiation strategies may constitute confidential information or trade secrets. Uploading such information to a public or vendor-operated generative-AI tool may disclose it to an unauthorised recipient or permit retention for model improvement.

Contracts should define confidential information, permitted purposes, security standards, personnel access, subcontracting, compelled disclosure, return or deletion, audit rights and remedies. Internal AI policies should prohibit the entry of restricted information into unapproved tools and require approved enterprise environments, access logging and retention controls.

7.2 Intellectual-property risks

AI procurement tools may create several IP problems:

• training data may have been used without appropriate rights;
• generated text may reproduce third-party protected material;
• outputs may not qualify for copyright protection in some jurisdictions;
• supplier submissions may be incorporated into training data;
• prompts, fine-tuning data and model weights may have uncertain ownership; and
• generated specifications may infringe patents, designs or confidential know-how.

A contract should address ownership and licence rights in inputs, outputs, prompts, configurations, fine-tuning data and improvements. It should include representations concerning lawful data use, indemnities where commercially appropriate, non-infringement procedures, human review and restrictions on training with customer data.

8. Accountability and governance framework

A mature digital procurement programme assigns responsibility rather than treating technology as an autonomous actor. A useful governance structure includes:

The three-lines model is useful: operational teams own risks; compliance and specialist functions support and challenge; internal audit provides independent assurance. Records should show not only the final decision but also who was responsible, what information was considered, what exceptions were approved and how risks were treated.

9. Applied case: AI-assisted supplier screening

Illustrative case. Meridian Components, a multinational manufacturer, introduces an AI tool to rank suppliers for a high-value electronics tender. The tool analyses historical delivery performance, financial data, sanctions screening, public information and questionnaire responses. It recommends excluding Nova Circuits because of “high continuity risk.”

Background and problem

Nova is a newer supplier with limited historical data but offers a technically superior product and a lower total cost. Nova requests the reasons for exclusion and discovers that the model treated a lack of historical deliveries as equivalent to poor performance. Its regional address also correlated with prior late-delivery records, although the relevant delays resulted from a discontinued logistics route. Meridian must determine whether the process was fair, lawful, secure and commercially defensible.

Analysis

The tool’s output is not a fact; it is a risk estimate derived from data and assumptions. The model has a data-quality problem: missing history is treated as negative evidence. It may also contain geographic proxy bias. If the decision has a significant effect, applicable privacy, equality, public-procurement or AI rules may require transparency, human involvement and an opportunity to challenge.

Meridian should examine the model version, input data, feature definitions, training methodology, validation results and decision threshold. It should check whether the platform lawfully obtained and used personal or business information, whether Nova’s confidential data were exposed, and whether the supplier contract permits the processing. It should preserve the original tender records and prevent retrospective alteration.

Approach and solution

Meridian pauses automatic exclusion and requires a qualified procurement panel to review the case. The panel separates “no evidence” from “negative evidence,” verifies current logistics capability, requests additional assurance, and applies the same supplementary evidence process to comparable suppliers. The AI vendor must provide documentation, security information, an explanation of the relevant factors and a model-correction plan.

Meridian changes the workflow so that the tool recommends rather than decides. It introduces minimum data-quality thresholds, missing-data flags, documented override reasons, periodic disparate-outcome testing and a supplier appeal route. The contract prohibits use of Meridian data for unrelated model training, requires incident notification, permits audit and requires deletion or return at termination.

Outcome

Nova is admitted to the next evaluation stage subject to a pilot order and enhanced delivery controls. Meridian avoids an unsupported exclusion, improves the model and creates a defensible audit trail. The organisation also discovers that its platform retained tender data longer than its approved retention schedule and corrects the configuration.

Learning points

1. A model can convert missing information into an unfair negative signal.
2. Human oversight must be substantive, not ceremonial.
3. Explainability requires records of data, model version, factors and thresholds.
4. Data protection, cybersecurity, procurement fairness and IP issues overlap.
5. Contractual rights to audit, correct, suspend and delete are essential.

10. Implementation roadmap and limitations

A practical implementation roadmap is as follows:

First, map the transaction. Identify systems, parties, data flows, jurisdictions, decisions, subprocessors and records.

Second, classify risk. Consider transaction value, criticality, personal data, confidential information, automation, supplier dependency and potential harm.

Third, design controls. Select authentication, approval, retention, security, privacy, transfer and AI-governance controls proportionate to risk.

Fourth, contract deliberately. Establish precedence, service levels, audit, data use, IP, security, incident response, liability, continuity, termination and dispute provisions.

Fifth, test before deployment. Conduct legal review, security testing, user acceptance, model validation, bias assessment and recovery exercises.

Sixth, monitor and improve. Review incidents, access, supplier performance, model drift, regulatory change and control effectiveness.

Important limitations remain. Laws differ by jurisdiction and evolve rapidly. Cloud architecture can make data location difficult to determine. Platform terms may be amended faster than procurement teams review them. AI explanations may be incomplete, and fairness metrics cannot resolve every normative question. Cybersecurity controls reduce risk but cannot guarantee prevention. Finally, contract allocation cannot eliminate the organisation’s regulatory duties or excuse poor internal governance.

Best-practice checklist

Before approving a digital procurement process, ask:

• Is the electronic record accessible, complete and tamper-evident?
• Are signers authenticated and authorised?
• Are platform terms incorporated clearly and version-controlled?
• Are data roles, purposes, retention and transfers documented?
• Are security duties measurable and supported by incident procedures?
• Can the organisation retrieve evidence after termination or a dispute?
• Is AI used only for a defined, lawful and necessary purpose?
• Are automated recommendations explainable, challengeable and monitored?
• Are confidential inputs protected from unauthorised model training?
• Are IP rights in data, software, prompts and outputs clear?
• Is there a named accountable owner and an effective audit trail?

Chapter Summary

Digital procurement law combines electronic-transactions law, contract law, evidence, data protection, cybersecurity, intellectual-property law and emerging AI regulation. Electronic signatures are legally meaningful when they reliably identify the signer, indicate intent, preserve integrity and connect the action to proper authority. Electronic records must be accessible, attributable, complete and retained through a controlled lifecycle.

Platform terms require careful attention to notice, assent, authority, precedence, amendments and exit rights. Smart contracts can automate performance but should operate within a clearly drafted legal agreement with oracle controls, testing and manual override. Data-protection compliance requires purpose limitation, minimisation, lawful processing, role allocation, security, retention and lawful cross-border-transfer mechanisms.

Cybersecurity is a shared contractual and operational responsibility. AI-supported sourcing must be governed through risk classification, data-quality controls, meaningful human oversight, transparency, bias assessment, model monitoring and accountability. Confidentiality and IP risks require restrictions on data inputs, training, outputs and vendor reuse. The central professional principle is that digital efficiency must be matched by evidential reliability, fairness, security and accountable human governance.

Key Terms

Electronic signature: Electronic data used to sign or indicate approval of a record.

Digital signature: A cryptographic form of electronic signature using key pairs and verification mechanisms.

Electronic record: Information created, stored or communicated in electronic form and capable of reproduction.

Functional equivalence: The principle that electronic methods may satisfy functions traditionally performed by paper or handwriting.

Technology neutrality: Legal design that avoids favouring one technical method unnecessarily.

Click-wrap: An online arrangement in which a user actively indicates acceptance, usually by selecting a button.

Browse-wrap: Terms allegedly accepted through use of a website without an express acceptance action.

Smart contract: Code that automatically performs actions when programmed conditions are met.

Oracle: A mechanism that supplies external data to a smart contract.

Metadata: Data describing a record, such as time, author, version or system source.

Hash: A fixed-length value used to help detect changes to digital data.

Personal data: Information relating to an identified or identifiable individual.

Controller: An entity that determines purposes and means of personal-data processing.

Processor: An entity that processes personal data on behalf of a controller.

Cross-border transfer: Movement or access to data across national or regulated territorial boundaries.

Automated decision-making: A decision produced wholly or substantially through automated processing.

Model drift: Change in model performance or data relationships after deployment.

Human oversight: Competent and effective human review, intervention and accountability in an automated process.

Trade secret: Confidential commercially valuable information protected through secrecy and legal rules.

Data minimisation: Limiting personal-data collection to what is necessary for the stated purpose.

Review Questions

Short Answer Questions

1. Distinguish an electronic signature from a digital signature.
2. Why is a PDF export not always a complete electronic record?
3. What is the function of an oracle in a smart contract?
4. Identify four core data-protection principles relevant to procurement.
5. Why are identity and authority separate controls in electronic contracting?

Long Answer Questions

1. Explain how functional equivalence and technology neutrality shape electronic-transactions law.
2. Discuss the contractual and operational controls required for a cloud procurement platform.
3. Analyse the legal and evidential significance of audit trails, metadata and retention holds.
4. Explain how a procurement organisation should govern cross-border data transfers.
5. Evaluate the intellectual-property and confidentiality risks of generative AI in sourcing.

Analytical / Application Questions

1. A supplier claims that its bid was rejected by an opaque AI score. Design a legally defensible review and appeal process.
2. A platform provider suffers a cyberattack and refuses to disclose details, citing confidentiality. Analyse the buyer’s contractual, regulatory and evidential options.
3. A smart contract automatically withholds payment because a delivery sensor supplied incorrect data. Allocate the likely legal and operational issues among the buyer, supplier, platform and oracle provider.

Multiple Choice Questions with Answers

Question 1

Which feature most directly supports the integrity of an electronic procurement record?

A. A colourful document template

B. An audit trail and tamper-detection mechanism

C. A verbal promise by the supplier

D. A low transaction value

Correct Answer: B. An audit trail and tamper-detection mechanism

Question 2

What is the principal distinction between an electronic signature and a digital signature?

A. Only digital signatures can be used in contracts

B. An electronic signature is broad; a digital signature is a cryptographic method

C. Electronic signatures require paper, while digital signatures do not

D. Digital signatures identify authority automatically

Correct Answer: B. An electronic signature is broad; a digital signature is a cryptographic method

Question 3

Which arrangement generally provides the strongest evidence of online assent?

A. Passive browsing without displayed terms

B. A hidden hyperlink in a footer

C. A clearly presented click-wrap acceptance action

D. Silence after receiving an email

Correct Answer: C. A clearly presented click-wrap acceptance action

Question 4

What is the primary purpose of a smart-contract oracle?

A. To appoint a company director

B. To supply external data to the code

C. To encrypt every customer record

D. To replace the governing law clause

Correct Answer: B. To supply external data to the code

Question 5

Which statement about hashing is correct?

A. Hashing proves that the author was truthful

B. Hashing helps detect whether data have changed

C. Hashing grants copyright ownership

D. Hashing replaces access controls

Correct Answer: B. Hashing helps detect whether data have changed

Question 6

A procurement platform provider processes personal data only on the buyer’s documented instructions. Which role is most likely applicable?

A. Processor

B. Data subject

C. Independent auditor in every circumstance

D. Oracle

Correct Answer: A. Processor

Question 7

Which is the best example of meaningful human oversight of an AI supplier-ranking tool?

A. A person automatically accepts every recommendation

B. A person reviews relevant evidence and can reject the output

C. The model is renamed as a manual process

D. The supplier is denied any explanation

Correct Answer: B. A person reviews relevant evidence and can reject the output

Question 8

Why can removing an explicit protected characteristic fail to eliminate bias?

A. Models cannot use any data

B. Other variables may operate as proxies

C. Human review always creates bias

D. Security controls cause discrimination

Correct Answer: B. Other variables may operate as proxies

Question 9

Which contractual provision is most relevant when a supplier’s generative-AI tool may use buyer data for training?

A. A restriction on data reuse and model training

B. A change to delivery packaging

C. A warranty concerning office furniture

D. A choice of font for invoices

Correct Answer: A. A restriction on data reuse and model training

Question 10

What should an organisation do when litigation is reasonably anticipated?

A. Delete all old records immediately

B. Suspend relevant routine deletion through a litigation hold

C. Allow every employee to edit records

D. Replace the original records with summaries

Correct Answer: B. Suspend relevant routine deletion through a litigation hold