A business buys recruitment software with an AI ranking feature. The supplier describes it as compliant, the procurement team completes its standard security review, and hiring managers begin using the rankings. The unresolved questions concern the deployment: which applicants are affected, what information is processed, how managers use the rankings, and which legal duties belong to the employer.
AI compliance requirements cannot be established from a product label alone. They depend on the jurisdiction, the organisation’s role, the purpose of the system, the data involved, and the consequences of its use. Buying a tool changes some responsibilities without answering all of those questions.
The practical task is to connect each applicable obligation to a control, an owner, and evidence that the control works. This article uses New Zealand privacy guidance and EU legislation as examples. They illustrate the assessment process rather than provide an exhaustive list of laws for every business. The EU implementation dates below were checked against the Commission’s timeline on 25 October 2026.
Establish the Deployment Before Classifying It
Create an inventory entry that describes the application in operational terms. For the recruitment tool, record whether it drafts advertisements, summarises applications, ranks candidates, or rejects them. Identify the people affected, the information used, the supplier services involved, and the decisions made by staff.
Include the deployment’s geographic reach. Where is the business established? Where is the system supplied or used? Where are affected people located? Where do outputs influence decisions? These facts help legal advisers assess territorial scope; the location of a server is only one part of that analysis.
Record the organisation’s role under each relevant regime. A business may deploy a purchased system while becoming responsible for additional obligations if it substantially modifies it or supplies a system under its own name. Data-protection roles require their own assessment. A supplier’s contractual description does not settle every statutory role.
An inventory should also capture AI features added to existing software. A service can change through a supplier update without a separate AI procurement project. Assign someone to review proposed feature activation and material changes so the assessment reflects the system actually in use.
Distinguish Legal Duties From Management Frameworks
Legislation, regulatory guidance, contractual commitments, and voluntary standards serve different purposes. Keeping them separate makes the basis for a requirement easier to explain and review.
The NIST AI Risk Management Framework is voluntary. ISO/IEC 42001 specifies requirements for an AI management system. They can support structured governance, but using a framework or obtaining management-system certification does not establish compliance with every law affecting a particular application.
A customer contract may also require specific assessments, security measures, or restrictions even where legislation does not impose the same wording. Record those commitments separately from statutory duties, including the contract and deployment to which they apply.
For the recruitment example, maintain a short applicability record that explains which employment, discrimination, privacy, and AI-specific rules need examination. Where a question remains unresolved, identify the facts or advice needed. A generic statement that the tool follows responsible AI principles is not a substitute for this work.
New Zealand Requirements: Existing Law and Voluntary Guidance
New Zealand’s approach combines existing legal duties with voluntary responsible-AI guidance. The government’s AI policy approach favours existing mechanisms over a standalone AI law. Businesses should assess the laws governing their activities rather than wait for an AI-specific compliance regime.
The table summarises key areas identified in MBIE’s compliance and legal obligations guidance, with practical questions for the deployment review. Sector-specific duties may add further requirements.
| Law or obligation | Relevance to business AI use | Question for the review |
|---|---|---|
| Privacy Act 2020 | Personal information in inputs, outputs, and service records. | What is collected, why, who receives it, and when is it deleted? |
| Fair Trading Act 1986 | Misleading conduct and representations, including AI-generated claims. | Who checks advertising, chatbot statements, and pricing claims? |
| Commerce Act 1986 | Competition restrictions, including algorithmic pricing collusion. | Could the pricing design or information exchange restrict competition? |
| Consumer Guarantees Act 1993 | Applicable guarantees for consumer goods and services. | Can the business meet quality, fitness, and service obligations when AI is involved? |
| Human Rights Act 1993 | Unlawful discrimination in protected areas, including employment, services, and housing. | Could the system disadvantage people on a protected ground? |
| Copyright Act 1994 and other intellectual property obligations | Rights in material supplied to or produced through the service. | What permissions and licences support the inputs and intended reuse? |
The Privacy Commissioner’s AI guidance recommends a privacy impact assessment before use. Include data minimisation, accuracy, security, retention, and overseas processing in that assessment. It is a practical way to investigate privacy obligations, rather than a claim that every AI use has an identical statutory assessment requirement.
For discrimination, examine the decision process and affected groups, including indirect effects from apparently neutral criteria. The Ministry of Justice’s Human Rights Act summary explains the protected grounds and areas. For intellectual property, establish input permissions and assess output rights separately; generated material should not be assumed to be free of third-party rights.
MBIE’s responsible AI guidance is voluntary. The New Zealand Institute of Directors’ AI governance guidance also supports board oversight. Use these resources to assign accountability, maintain a risk register, establish staff policies, and design appropriate human oversight. Those management practices support compliance without replacing applicable law.
Assess the EU AI Act by Scope, Role, and Application Date
The EU AI Act distinguishes roles including providers and deployers, prohibits certain practices, and places requirements on specified system categories. Its territorial scope can include some organisations outside the EU. Assess the deployment against the current text rather than assuming the organisation’s headquarters determines applicability.
Recruitment and candidate-selection uses appear in Annex III’s high-risk categories, subject to the Act’s classification provisions and exceptions. The task performed by the system matters. Establish the classification and role before selecting the applicable obligations.
The Commission’s implementation timeline currently records these milestones: general provisions, AI literacy, and prohibitions applied from 2 February 2025; general-purpose AI rules from 2 August 2025; and the majority of rules, including Article 50 transparency requirements, from 2 August 2026. Following amendments, it lists 2 December 2027 for Annex III high-risk rules and 2 August 2028 for high-risk AI embedded in Annex I regulated products. Transitional provisions require separate checking.
Use those dates to plan the relevant work, with an owner responsible for checking changes. A later deadline for one category does not suspend existing privacy, employment, or other applicable obligations.
Check Prohibited Practices and High-Risk Obligations
A New Zealand business may fall within the Act when supplying systems to the EU or, in specified circumstances, when outputs are used there. Check Article 2’s territorial scope against the actual arrangement. Having an overseas customer is a reason to investigate applicability, rather than sufficient evidence of the result.
Article 5 prohibits specified practices, including certain harmful manipulation, social scoring, and real-time remote biometric identification by law enforcement in publicly accessible spaces, subject to the provision’s conditions and exceptions. It is not a blanket ban on every scoring or biometric application. Article 99 provides maximum penalties for prohibited-practice infringements of up to EUR 35 million or 7% of worldwide annual turnover, with specific rules for undertakings and SMEs. The applicable penalty depends on the infringement and circumstances.
High-risk categories include specified uses in recruitment and employment, education, critical infrastructure, and creditworthiness assessment. Classification depends on the intended use and legal provisions; not every system in those sectors is automatically high-risk. For a classified system, distinguish the provider’s engineering and conformity duties from the deployer’s operating duties.
| High-risk compliance area | What to establish for the relevant role |
|---|---|
| Risk management | Lifecycle risk assessment, mitigation, testing, and reassessment arrangements. |
| Data governance | Applicable quality and governance controls for training, validation, and testing data. |
| Documentation and records | Technical documentation, logging capability, and role-specific record retention. |
| Human oversight | Competent people with the information and authority needed to interpret, override, or stop use where appropriate. |
| Conformity and registration | The provider’s applicable conformity assessment, declaration, marking, and registration; any separate deployer registration duties. |
| Operation and monitoring | Use within instructions, monitoring, incident handling, and communication with the provider. |
These areas draw on provider obligations under Article 16 and deployer obligations under Article 26. Allocate each requirement by role and application date. Do not assign every provider duty to an employer simply because it uses purchased recruitment software.
Separate Transparency Duties From Minimal-Risk Uses
Article 50 establishes specific transparency duties. Providers of systems interacting directly with people must generally make that interaction clear unless it is obvious in context. Providers of systems generating synthetic content have machine-readable marking duties, subject to technical qualifications and exceptions.
Deployers have separate disclosure duties for deepfakes and certain AI-generated public-interest text. The text provision includes an exception for human review or editorial control with editorial responsibility. This does not create a universal requirement to label every AI-assisted email or document. Determine which duty applies to the content, role, and use, including relevant transition arrangements.
Minimal-risk systems do not attract the high-risk requirements merely because they use AI. Privacy, consumer, employment, intellectual property, and contractual obligations can still apply. Transparency duties and high-risk classification are separate questions that may overlap in a particular deployment.
Follow Personal Information Through the Whole Service
Map the information entering the application, the supplier services receiving it, and the records retained afterwards. Include prompts, uploaded documents, retrieved passages, generated assessments, support access, and logs. Restricting model training does not by itself establish that no information is retained or accessible elsewhere.
New Zealand’s Privacy Commissioner explains that the Privacy Act applies to AI use and recommends completing and updating a privacy impact assessment. Examine collection, purpose, accuracy, security, use, disclosure, and retention in the specific workflow. The assessment should influence the design before live applicant information is introduced.
Overseas processing needs careful analysis. The Commissioner’s Principle 12 decision tree distinguishes disclosure from sending information to an agent solely for storage or processing where it does not use or disclose it for its own purposes. An overseas server does not automatically establish which situation applies. Examine the actual service and terms, including any independent supplier uses.
Where the EU GDPR applies, assess its requirements separately, including lawful processing, transparency, rights, security, processor arrangements, and international transfers. A data protection impact assessment is required under Article 35 where processing is likely to result in high risk to individuals’ rights and freedoms; it is not automatically mandatory for every AI feature. The regulation’s text provides the legal basis for that assessment.
Examine What Human Review Actually Changes
A recruitment application can produce a recommendation while strongly determining the eventual outcome. Establish whether managers inspect relevant evidence, consider additional information, and have the authority and practical ability to change the result.
Under EU GDPR Article 22, the relevant restriction concerns decisions based solely on automated processing that produce legal or similarly significant effects, with specified exceptions and safeguards. It does not cover every automated recommendation. The EDPB’s guidance on automated decision-making explains the importance of meaningful human involvement when assessing the decision process.
For the employer, that means examining the workflow rather than relying on a manager’s name beside an approval. If staff routinely accept rankings without reviewing the basis, the organisation needs to investigate whether its claimed oversight corresponds to practice. Provide time, relevant information, training, and an escalation route for disputed cases.
Fairness assessment needs similar specificity. Identify the affected groups, the possible disadvantages, and the evidence relevant to the applicable law. A single aggregate accuracy measure cannot answer every discrimination question. Document what was tested, the limitations of the evidence, and how concerns will be investigated after deployment.
Turn Supplier Assurances Into Reviewable Evidence
Ask for evidence relevant to the contracted configuration: permitted uses, data handling, security controls, evaluation, changes, incident notification, subcontractors, and assistance with individual rights. Clarify which responsibilities the supplier performs and which remain with the business.
For recruitment software, evidence should address the intended selection use and its limitations. A general benchmark on language tasks will not establish that candidate rankings are suitable for the employer’s jobs or applicant population. Local evaluation and legal assessment may still be necessary.
Review rights in inputs and outputs separately from privacy. Applicant documents, internal materials, and licensed content can involve confidentiality, copyright, and contractual restrictions. Supplier terms allocating output rights do not automatically resolve all third-party claims. Identify the actual materials and intended reuse before concluding that the terms are sufficient.
New Zealand’s responsible AI guidance for businesses supports responsible practice while expressly preserving the need to follow applicable legislation. Use guidance to organise the assessment, with legal conclusions grounded in the rules governing the deployment.
Keep the Evidence Useful After Approval
A compliance record should connect obligations to operational evidence: notices supplied to applicants, access settings, assessment findings, evaluation results, approved conditions, supplier terms, and responsible owners. Retain what is necessary to explain decisions under the applicable requirements, with appropriate protection and disposal arrangements.
Check that the evidence can be retrieved by the people who need it. If a candidate challenges a ranking after the supplier has changed its model, the employer may need the relevant application version, criteria, and decision record. Establish those requirements before procurement so the contract and logging design support the expected process. Keeping extensive logs without a retrieval method or defined purpose would not solve that problem.
Define triggers for reassessment. A new model, expanded applicant population, changed ranking criteria, additional data source, or move from recommendations to automatic rejection can change the legal and risk analysis. Supplier updates need to reach someone authorised to make that judgement.
Prepare for complaints and incidents. Staff should know how to locate relevant records, preserve evidence, restrict the feature, and route the matter for assessment of any notification or reporting obligations. Different laws have different triggers and deadlines; do not treat every AI error as one universal reportable event.
Practical Business Compliance Checklist
Use these steps to turn the assessment into an operating process:
- Map the AI inventory. Include standalone tools, employee-used chatbots, embedded software features, suppliers, owners, and affected countries.
- Classify each use. Identify personal information, employment or financial consequences, international reach, legal roles, and any prohibited or high-risk features.
- Publish an acceptable-use policy. State approved tools, permitted data, prohibited inputs, disclosure expectations, and how staff request approval. Explain why a personal or free account may have different terms and controls from an approved business configuration.
- Assign meaningful human review. Prioritise external-facing, legal, financial, and other consequential outputs; specify who verifies them, against which sources, and when to escalate. Set this as a business control according to the use and applicable duties, rather than assuming one universal review rule applies to all AI output.
- Maintain evidence and reassess. Retain relevant approvals, supplier terms, evaluations, notices, and decision records, and review material changes and incidents.
The agent governance framework examines additional controls when systems can take actions. The adoption strategy connects these requirements to investment and release decisions. For the recruitment deployment, the resulting compliance position should explain what the system may do, why that use is permitted, what safeguards apply, and how the business will detect when those conclusions need to be revisited.
