Buying an AI tool doesn't decide how employees can use it. Under the EU AI Act, each use case needs its own risk check, owner, and rules people can follow.
Your high-risk AI policy must connect each approved use case to a classification decision, a responsible owner, and operating instructions people can follow. This guide explains that process, with a separate section for companies developing and selling AI systems.
TL;DR
- Build your high-risk AI policy around Article 6 classification and Article 26 operating duties.
- Businesses using AI systems are generally deployers; providers have separate development and market-entry obligations.
- Record the approved purpose, human oversight, monitoring, information duties, and escalation route for each system.
- A policy template supports implementation; it does not establish legal compliance or replace technical controls.
Why this matters for businesses using AI
Buying an AI tool does not settle how your employees can use it. A recruiting system that filters applications presents different questions from an assistant drafting a generic interview invitation. Your policy needs to distinguish those activities before permission for one becomes permission for both.
The business goal is workable governance: employees know their approved task, protect information, check results, and ask the right person. Higher-risk activities need additional review and system-specific controls. A general instruction to use AI responsibly leaves those decisions unresolved.
This guide uses the EU AI Act as its legal framework, rather than an invented scoring model. It is a policy-design guide, not a validated compliance assessment or legal advice. Global companies must assess the Act’s territorial scope against their operations and the use of system outputs in the EU.
Start with classification, not the policy template
Under Article 6, high-risk classification has two principal routes: specified product and safety-component situations covered by Annex I, and the uses listed in Annex III. The product route includes conditions concerning applicable product legislation and third-party conformity assessment.
Annex III covers defined uses in areas including employment, education, essential services, biometrics, and critical infrastructure. It does not classify every activity in those departments as high-risk.
Examples that warrant classification review include:
- Recruitment: An AI system analyzing or filtering job applications or evaluating candidates.
- Worker management: A system evaluating employee performance or allocating tasks based on individual behavior or personal characteristics.
- Credit: A system assessing individuals’ creditworthiness, with the stated exception for financial fraud detection.
- Education: A system assessing learning outcomes in educational or vocational training institutions.
Article 6(3) contains a conditional exception for certain Annex III systems that do not pose significant risks, including through not materially influencing decisions. A task being described as preparatory is not enough by itself. Annex III systems performing profiling of people remain high-risk under that provision.
Record the reasoning and evidence behind the classification. A department label, supplier slogan, or internal risk score is not a substitute for applying the legal criteria.
Check the application dates for your system
The European Commission’s AI Act overview, updated Oct. 19, 2026, reports the amended high-risk application timetable:
- Dec. 2, 2027: Rules for high-risk uses in the specified Annex III areas.
- Aug. 2, 2028: Rules for high-risk AI embedded in regulated products.
Those dates should not be read as permission to disregard existing privacy, employment, safety, or other applicable law. Separate AI Act provisions, including prohibited practices and transparency requirements, have their own scope and timetable. Existing systems can also require a transition assessment.
For a policy prepared in 2026, record the applicable date and transition reasoning in the use-case file. Have legal counsel confirm them for the specific system before deployment.
Build a high-risk AI policy for businesses using AI systems
A business using an AI system under its authority is generally a deployer, the Act’s term for the organization operating it. Article 26 supplies the core framework for high-risk operating duties. Translate that framework into a company policy and a maintained record for each approved use case.
The following steps organize implementation. They are not an official EU template or a separate certification standard.
Define the approved purpose and approval authority
Describe the decision the system supports, the people affected, and the environment in which it operates. Approval should attach to that combination, rather than to a product name alone.
As an illustrative example, approving a tool to draft vacancy descriptions does not approve using it to score applicants. Changing the task should trigger review before employees proceed.
Include:
- The system, supplier, version, and approved environment.
- The intended purpose and prohibited extensions of that purpose.
- The classification decision and supporting supplier information.
- The business owner and people authorized to approve changes.
Assign human oversight with real authority
Article 26 requires oversight by people with the necessary competence, training, authority, and support. Naming a manager in a document does not explain how that manager checks the system’s use.
Connect the oversight role to the provider’s instructions and the actual workflow. The person needs to understand the relevant limitations and know how to respond when an output is unreliable.
Specify:
- Who performs oversight and who covers absences.
- What information and system controls those people can access.
- What they check before an output informs action.
- How they challenge outputs and stop or escalate use.
Control inputs and follow the provider’s instructions
Article 26 requires appropriate technical and organizational measures to use the system according to its instructions. Where the business controls input data, it must ensure that the data is relevant and sufficiently representative for the intended purpose.
Your policy should connect those duties to information handling. An approved system does not make every upload appropriate, and training cannot enforce access restrictions on its own.
Document:
- The information employees are allowed to supply.
- Who checks input relevance and representativeness where required.
- The approved access route and configuration.
- Where employees find current operating instructions.
Monitor operation and define the stop route
Monitoring should follow the instructions for use and connect observed problems to an accountable decision. Avoid inventing a universal accuracy threshold or review interval for unrelated systems.
Article 26 distinguishes risk-related notifications and suspension from serious-incident reporting. Your procedure should preserve those distinctions, with named contacts who can act without waiting for a routine committee meeting.
Set out:
- What operational information the owner reviews.
- The provider’s limitations and warnings relevant to that review.
- How employees report suspected risks or serious incidents.
- Who suspends use and handles required external notifications.
Keep records and provide required information
For automatically generated logs under the deployer’s control, Article 26 specifies retention appropriate to the purpose and at least six months, unless applicable EU or national law provides otherwise. This is not a blanket instruction to retain all personal data indefinitely.
Employers must inform workers’ representatives and affected workers before workplace use of a high-risk system, subject to the applicable information procedures. Annex III systems making or assisting decisions about individuals also carry an information duty toward those individuals.
Assign responsibility for:
- Log access, retention, and protection.
- Worker and affected-person notices where required.
- Applicable privacy assessments and supporting provider information.
- Additional registration checks where the deployer is a public authority.
Assess additional duties and teach the workflow
A fundamental rights impact assessment is not mandatory for every private business using high-risk AI. Article 27 specifies the deployers and uses covered, including certain public-service, creditworthiness, and life or health insurance situations. Check its scope separately from any data protection impact assessment.
Train employees on the decisions they actually make. Under the amended Article 4, providers and deployers must take measures supporting AI literacy development; it does not require guaranteeing a specific individual literacy level. High-risk oversight roles still require their own competence, training, and authority.
Use workplace practice to check whether employees can:
- Recognize the approved task and its boundaries.
- Identify information they can enter.
- Explain the relevant output checks.
- Find the person who can resolve uncertainty or stop use.
These practice checks inform instruction. They are not legally validated pass marks or proof of compliance by themselves.
What belongs in the use-case policy record?
Keep the shared company rules short and attach system-specific information where it can be maintained. This structure separates general employee permission from the evidence supporting a particular high-risk deployment.
| Record component | What it should identify | Evidence to attach or reference |
|---|---|---|
| Purpose and classification | Approved activity, affected people, and legal reasoning | Intended-purpose information and classification assessment |
| Approval and ownership | Decision-makers and any unresolved conditions | Approval record and assigned responsibilities |
| Operating boundaries | Inputs, environment, configuration, and excluded activities | Provider instructions and access controls |
| Oversight and training | Named people, authority, and necessary preparation | Oversight procedure and relevant training records |
| Monitoring and incidents | Checks, suspension authority, and notification route | Operating records and incident procedure |
| Information and retention | Required notices and recordkeeping arrangements | Notices, retention rules, and applicable assessments |
Suggested policy wording, to adapt after specialist review: Employees may use the system only for its documented approved purpose and within its operating instructions. The assigned owner maintains the use-case record, ensures oversight responsibilities are covered and routes material changes for review before use expands.
That wording is an implementation example, not language prescribed by the Act. Your policy must identify the actual people, controls, and evidence behind it.
What changes for companies developing and selling AI systems?
Companies developing an AI system, or having one developed, and placing it on the market or putting it into service under their own name can be providers. Provider status is not limited to software vendors selling subscriptions; internal development can also require assessment.
For high-risk systems, Article 16 points to a wider set of responsibilities. These include meeting system requirements, maintaining a quality management system and documentation, completing the applicable conformity assessment, and handling relevant declarations, marking, and registration.
| Business role | Main policy focus | Key limitation of an employee-use policy |
|---|---|---|
| Business using a high-risk system | Approved operation, oversight, monitoring, and records | Does not resolve provider obligations |
| Company developing and supplying a high-risk system | Development controls, conformity and lifecycle responsibilities | Cannot replace technical documentation or assessment |
| Organization performing both roles | Separate responsibilities for each system and activity | One companywide label can conceal different duties |
A provider’s governance arrangements should connect product development, risk and data controls, testing, customer instructions, post-market monitoring, and corrective action. Employee training supports those processes; it cannot replace them.
A business buying AI should also reassess its role before rebranding, substantially modifying, or changing a system’s intended purpose. Changes can bring provider responsibilities into scope. Obtain a specific assessment rather than assuming the supplier continues to carry every obligation.
Common policy mistakes to avoid
- Calling every AI use high-risk. Apply Article 6 and the relevant annex to the actual intended purpose.
- Treating supplier approval as workflow approval. Check the proposed task, inputs, and decisions separately.
- Assigning oversight without authority. The named person needs training, access, support, and a workable stop route.
- Using course completion as a compliance verdict. Participation records do not establish that operating duties are fulfilled.
- Writing deadlines from an older checklist. Check current application dates and transition provisions for the system.
FAQ
What should a high-risk AI policy include?
A high-risk AI policy should identify the approved purpose, classification, owners, operating boundaries, human oversight, monitoring, records, and escalation route. Businesses using systems should connect those arrangements to Article 26 and the provider’s instructions.
Is every business AI tool high-risk under the EU AI Act?
No. Classification depends on Article 6 and the applicable product rules or Annex III use case, including relevant conditions and exceptions. Assess the intended purpose rather than classifying every tool used by a department alike.
Are businesses buying AI systems deployers or providers?
Businesses using AI systems under their authority are generally deployers. Developing, rebranding, or modifying systems can require a separate provider-role assessment.
When do the high-risk AI rules apply?
The Commission’s October 2026 overview gives Dec. 2, 2027, for specified high-risk areas and Aug. 2, 2028, for high-risk AI embedded in regulated products. Confirm the applicable route and transition provisions for the specific system.
Must every business complete a fundamental rights impact assessment?
No. Article 27 identifies the deployers and uses subject to that duty. Assess its scope separately from privacy-law assessment requirements.
How long must deployers keep high-risk AI logs?
Article 26 specifies a purpose-appropriate period of at least six months for automatically generated logs under the deployer’s control, unless applicable law provides otherwise. The rule does not authorize unrestricted personal-data retention.
Does AI training make a high-risk deployment compliant?
No. Training supports literacy and competent oversight, while compliance also depends on the applicable operating duties, technical measures, and system-specific evidence. A course certificate does not replace those requirements.
