Artificial intelligence has long since arrived in the everyday work of many Austrian companies: employees have texts summarized, prepare presentations, compare job profiles, or draft responses for customers. However, a common answer to the crucial questions is often missing: Which tools are approved? Which data may be entered? Who checks a result before it leaves the company? A practical AI policy in the company turns individual experiments into a controlled process.
This does not require a hundred-page rulebook or a general ban. Good guidelines are short enough to be read in everyday life and concrete enough to enable real decisions. They combine data protection, information security, quality control, work organization and AI competence. This guide shows how Austrian companies and teams can arrive at robust rules in manageable steps.
Why an AI policy is more than just a 'No' sign
Without clear rules, two extremes usually arise. Some employees use publicly available AI services with sensitive information because they are not aware of the risks. Others forego useful assistance even for harmless tasks because they have not received approval. Both cost quality and time. A policy creates a secure space for action: it describes permitted applications, limits, responsibilities, and the path for new ideas.
The Austrian Economic Chamber recommends that companies adapt individual AI guidelines to their own needs. This concerns, among other things, trade secrets, personal data, third-party rights and human responsibility. The European AI Act complements this framework. Article 4 requires measures to ensure appropriate AI competence for those persons who deploy AI systems on behalf of an organization. According to the Austrian AI Service Center of the RTR hängt das notwendige Wissen vom System, vom Einsatzkontext und von der Erfahrung der betroffenen Personen ab.
An internal policy does not replace legal advice or the review of a specific AI system. However, it ensures that a company identifies risks early, documents decisions in a traceable way, and does not leave training to chance.
Step 1: Record real AI usage instead of an idealized picture
Before rules are formulated, the project group needs an honest inventory. A short, non-punitive survey of the teams is usually more helpful than asking which systems were officially procured. At a minimum, the tool, purpose, data used, recipient of the result, frequency and responsible role should be recorded. Functions in already licensed Office, CRM, support, or recruitment/applicant-tracking programs also belong on the list.
For each use case, six guiding questions help:
- What specific task should the AI assist with?
- Who enters inputs and who checks the result?
- Do the inputs contain personal, confidential, or copyright-protected content?
- Does the result affect or influence decisions about people?
- Is the AI content used internally or published externally?
- What consequences would a false, biased, or publicly disclosed result have?
The inventory is not a one-off Excel project. It becomes the company's ongoing AI map. New systems and significantly changed use cases are added, not introduced silently.
Step 2: Categorize use cases with a simple traffic-light system
Teams need a decision aid that also works under time pressure. For many small and medium-sized businesses, a three-level traffic light is sufficient at first. It is an internal working tool and not a legal risk classification under the AI Act.
Green: authorized assistance with non-sensitive data
This can include brainstorming, outlines, language correction, or summaries of publicly available information. The prerequisites are that an approved tool is used, no confidential data is entered, and a human reviews the output. Even in green cases, fact-checking and labeling obligations remain relevant.
Yellow: Use only with additional approval
Yellow includes, for example, drafts for customer communications, analyses of internal documents, translations of legally relevant texts, or AI support in recruiting. These require a designated specialist approval, a documented data review, and often the involvement of data protection, information security, HR, or the works council.
Red: prohibited or blocked pending review
This group includes, for example, entering passwords, health data, unvetted application documents, or trade secrets into non-approved services. Likewise, fully automated personnel decisions, manipulative applications, and systems for emotion recognition in the workplace should not be treated as ordinary team experiments. The AI Act contains explicit prohibitions for certain practices and strict requirements for certain applications in the employment sector. Such projects require a qualified legal and technical review in advance.
Step 3: Clearly name tools and data classes
The phrase "use AI responsibly" is too vague. The policy should include a current positive list of approved services or refer to a centrally maintained register. For each tool, permitted user groups, approved use cases, contractual status, storage and training options, as well as an internal contact person should be specified.
In parallel, the company defines understandable data classes. One possible classification is: public, internal, confidential, and specially protected. For each class it is determined whether it may be entered into a particular AI system. Examples of specially protected data include application data, personnel files, health information, access credentials, and trade secrets. The WKO notes in its Guidance on customer-related data and AI indicating that a legal basis is required for processing and that confidential and personal information must be handled with particular care.
A good everyday rule is: minimize data first. Names, contact details, internal metrics, or identifying details are removed if they are not required for the task. Pseudonymization only helps if re-identification is actually made more difficult. For example, "customer Anna Huber from Graz with contract number 4711" becomes "a private customer with an ongoing contract" if the identity is irrelevant to the question.
Step 4: Distribute responsibility along the workflow
An AI policy won't work if every question lands with management. It needs clearly assigned roles:
- Executive management or department heads: approves the risk framework, resources, and responsible parties.
- Tool owners: check vendors, contracts, configuration, access, and changes.
- Subject-matter experts: define quality criteria and approve sensitive results.
- Data protection and information security: assess data flows, security measures, and incidents.
- HR and works council: are involved early in employee-related applications.
- Users: comply with data rules, check results, and report errors.
In small businesses, one person can take on multiple roles. What matters is not the number of functions, but that, before deployment, it is clear who may decide, review, and stop.
Step 5: Human review as a concrete quality gate
The phrase "results must be reviewed" is not enough. The policy should define, for each use case, what is to be checked. For a public text, this includes facts, sources, tone, discriminatory statements, third-party rights, and personal data. For a spreadsheet analysis, input data, the calculation method, outliers, and plausibility must be checked. For software code, tests, security checks, and review are added.
The four-eyes principle is helpful for content with high external impact or consequences for people. For example, an application must not be screened out on the basis of an unchecked AI summary. Those who use AI in recruiting must clearly separate purpose, the data set, and the human decision. The jobspot.at guide also provides guidance on the responsible handling of application data When application data must be deleted after a rejection.
For generated content, a convincing formulation is not proof. Sources are opened, claims are compared with original documents, and numbers together with their reference periods are checked. If the origin of a result is not traceable, it must not be passed on as an established fact.
Step 6: Build AI competence by role
Not all employees need the same training. An assistant who drafts minutes faces different risks than a recruiter, a developer, or an executive. The AI Actnames technical knowledge, experience, training and the context of use as factors for an adequate level of competence. The RTR also emphasizes that the requirements are role- and system-dependent.
A lean training model can consist of three levels:
- Foundation for all:How generative AI works and its limits, data classes, permitted tools, fact-checking, reporting channel.
- Practical training for user groups:Exercises with typical tasks, good inputs, quality criteria and error cases for the respective team.
- In-depth training for those responsible:AI Act, data protection, procurement, risk assessment, documentation and incident management.
Participation, content, and date are documented in a traceable manner. A one-time webinar is not sufficient in the long term. New functions, provider terms, legal requirements, and real-world incidents are incorporated into short refreshers. The EU Commission provides a repository with examples of AI competence measures. It serves as inspiration, but according to the Commission, it does not replace individual proof of one's own implementation.
Step 7: Create a clear approval process for new AI ideas
If approval takes several months, usage will move into the shadows. A practical process begins with a short form: problem, desired tool, data class, affected persons, expected benefit, responsible person, and planned test period. The responsible department decides within a set deadline whether the case is approved, tested with conditions, or subjected to in-depth review.
For a pilot, success and termination criteria should be defined in advance. Suitable metrics include time savings, error rate, rework effort, user feedback, and the number of data protection or security incidents. "The answers sound good" is not a reliable success criterion.
The approval applies only to the described purpose. A service that has been approved for marketing drafts is not automatically approved for resume analysis, performance evaluation, or contract review.
Step 8: Report incidents without hiding them
Input errors and incorrect results will never completely disappear. Therefore the policy needs a simple reporting channel. Examples include accidentally uploaded personnel data, trade secrets that have become public, discriminatory suggestions, incorrect legal advice, or AI-generated content that is not labeled.
The immediate rule should be easy to remember: stop using, don't share further, secure evidence, and inform the designated contact. Afterwards it will be determined whether access should be revoked, content withdrawn, affected individuals informed, or further internal and legal actions taken. A factual error culture is a security factor. Those who fear sanctions for every report will report too late.
A sample structure for the internal AI policy
The actual document can work for an SME on just a few pages. The following chapters cover the most important decisions:
- Purpose, scope, and definitions
- Approved tools and permitted use cases
- Disallowed applications
- Data classes and input rules
- Human review and approvals
- Transparency, copyright and external communication
- Special rules for staff, customers and sensitive areas
- Roles, training and documentation
- Reporting procedure for errors and incidents
- Review, version and next update
Formulations should describe observable behavior. Instead of 'Use AI ethically' it is clearer to state: 'External texts are reviewed before publication by a subject-matter responsible person for facts, sources, third-party rights and personal data.' Instead of 'Do not enter sensitive data' the policy should provide concrete examples and list the permitted systems.
Practical example: Introduction in an Austrian service company
A company with 45 employees discovers six AI tools that are used regularly. The project group decides against an immediate total ban and instead inventories twelve use cases. Spell checking and idea generation using public information are classified as green. Drafts for customer responses are classified as yellow and must come from the approved system; personal customer data is removed beforehand and the responsible specialist signs off on the reply. The automatic evaluation of job applications remains red until HR, data protection, and the works council have reviewed the specific deployment.
Within four weeks the company publishes a three-page policy, a tools list, and a one-page quick guide. All employees complete a basic module, and affected teams practice with anonymized cases. After eight weeks the evaluation shows: processing time for standard drafts decreases, while several unreliable sources are detected. The policy is therefore expanded to include a mandatory source check. That is exactly how the document should function: as a learning operating system, not as a repository in the intranet.
Checklist before approval
- Is actual AI usage captured in all teams?
- Is there an up-to-date list of approved tools and their purposes?
- Are data classes defined with clear examples?
- Are prohibited or review-required applications clearly identified?
- Is a human sign-off specified for every sensitive process?
- Are HR, data protection, information security and the works council appropriately involved?
- Is there role-based training and proof of attendance?
- Is the reporting procedure for errors and data incidents known?
- Does each version have a responsible party and a review date?
- Has the policy been tested in real-life everyday situations?
Frequently asked questions about the AI policy
Does every company need its own policy?
A general template is a good start, but it does not reflect the systems used, data, roles, and risks of a specific company. Therefore, every company should adapt the document to its processes. The WKO online form for AI guidelines can provide guidance.
Does an AI officer need to be appointed?
RTR explains that the AI Act does not generally require the appointment of an AI officer. Responsibilities still need to be clearly defined. In small companies, a cross-departmental team or a designated coordination role can be more appropriate than a new title.
Are employees allowed to use free AI tools?
Price does not determine suitability. Relevant factors are contractual terms, data processing, configuration, security level, and the specific purpose. Unvetted services should not be used for internal, personal, or confidential information.
How often should the policy be updated?
At minimum when new tools are introduced, functions change, new legal requirements arise, or an incident occurs. In addition, a fixed review schedule is useful, for example every six months. That way the allowlist stays up to date and lessons learned from practice are incorporated.
Conclusion: Clear rules are what make responsible use possible in the first place
An effective AI policy does not start with abstract principles but with a team's real tasks. It specifies allowed tools, protects data, allocates responsibility and makes human review measurable. Role-based training and an open reporting channel ensure the rules hold up in everyday practice.
Start with a two-week inventory and three common use cases. Classify them using a traffic-light system, designate responsible parties, and test the rules with the teams involved. Only after that is the first version adopted. This creates, step by step, a secure framework that enables innovation rather than merely promising it.
